A Practical Guide to Using the Vector Database Console for Everyday Administration

Once a vector database is running and populated with data, someone has to keep an eye on it. That means checking whether queries are slow, knowing which API keys belong to which services, making sure the right people have the right level of access, and occasionally running a quick query to verify that the data looks correct. These are routine administration tasks — not glamorous work, but the kind that prevents problems from quietly growing into outages.

Most managed vector database platforms provide a web console for exactly this. The console is the operational layer between your data and the infrastructure running it. Understanding what lives where, and what you can actually do from the UI versus what requires code, makes day-to-day administration significantly less frustrating.

This guide covers the practical side of console administration — what to monitor, how keys and roles are managed, and how to use the built-in query tools — using the Weaviate Cloud console as the concrete example.

What a Vector Database Console Is Actually For

The console is not where you build your application. It is where you operate it. The distinction matters because developers sometimes ignore the console entirely, preferring to do everything through the API or client library. That works until something goes wrong and you need to quickly check object counts, find out which key is being used by a failing service, or verify that a recent ingestion actually landed.

A good console gives you immediate visibility into the state of your data and infrastructure without requiring you to write diagnostic code on the spot. It also handles tasks that are genuinely easier to do through a UI — creating API keys, configuring roles, reviewing metrics dashboards — than through API calls.

Getting Into the Console

For Weaviate Cloud, the console is at console.weaviate.cloud. After logging in, your clusters appear in the sidebar. Each cluster is a separate deployment — if you have a sandbox for testing and a production cluster, they appear as distinct entries and are administered independently.

Clicking a cluster opens its detail panel, which is the main workspace for everything covered in this guide.

Monitoring Cluster Health

The first thing worth knowing is what your cluster is actually doing. The cluster details panel surfaces the numbers you will reach for most often:

• Object count — how many vectors are stored
• Dimensions — confirms the embedding size matches what your ingestion pipeline is producing
• Cluster expiry — relevant for sandbox clusters, which have a 14-day lifetime
• Endpoints — the REST and gRPC URLs your application connects to, useful when onboarding a new service or debugging a connection failure

Beyond the headline stats, the metrics section shows query latency, ingestion throughput, average batch size, and object count over time. These are the signals that tell you whether performance is stable or degrading. A spike in query latency after a new deployment is the kind of thing you want to see immediately, not when a user reports that search feels slow.

The cluster details panel also shows the Weaviate version, cloud provider, and region — details that matter when checking compatibility with a client library or verifying that data is stored in the right geography.

Managing API Keys

The API Keys section is where you control programmatic access to the cluster. Each key is a credential that grants a specific level of access, and the console makes it straightforward to create, rotate, or remove keys without touching your application code.

Creating a key: Click New key, give it a descriptive name (something that identifies the service or person using it, not just key1), assign a role, and save. Copy the key immediately after creation — the console will not show it again. If you miss it, you will need to rotate the key to get a new value.

Rotating a key: Clicking Rotate on an existing key invalidates the old value and generates a new one. This is the correct response when a key may have been exposed, or when a teammate who had access to it leaves. The key name and role assignment carry over — only the credential value changes.

Editing a key: You can update a key’s name or reassign its role without rotating it. Useful when responsibilities shift and a service that previously needed read access now needs to write data as well.

Deleting a key: Deletion is permanent and requires typing the key name to confirm. Use this when decommissioning a service, not when you just want to change access levels — edit or rotate instead.

Managing Roles

Roles define what a key is allowed to do. Without role-based access control, every key has the same permissions, which means a compromised read-only service key could delete your entire index. The Roles section in the console lets you create fine-grained permission sets and assign them to keys.

Creating a role: Give it a name, then configure which collections it can access and which operations it can perform — create, read, update, and delete can each be toggled independently. A role for a search service might have read access on your content collections and nothing else.

Editing a role: Changes take effect immediately for all keys assigned to that role. If you update a role to remove write access, every key using that role loses write access without you needing to touch the keys themselves. This is the right model for access changes that affect a class of services rather than one specific key.

Built-in roles: The admin and viewer roles exist by default and cannot be deleted. Admin grants full access; viewer is read-only. These cover most cases for small teams. Custom roles are useful when you need something in between — for example, a role that can write to one collection but only read from another.

Running Queries from the Console

The Query Module is the console’s built-in GraphQL IDE. It is useful for a few specific scenarios: verifying that data looks correct after ingestion, testing a query before implementing it in code, and debugging unexpected search results without setting up a local script.

The IDE includes syntax highlighting, type-ahead for fields and arguments, and real-time error highlighting. It connects directly to your cluster using your current session credentials, so there is no separate authentication step.

The query interface is not a replacement for testing in code — results in the IDE are fine for spot-checking but do not capture the full context of how your application assembles queries. Think of it as a fast inspection tool, not a development environment.

Creating New Clusters

From the sidebar, clicking the + button opens the cluster creation flow. Weaviate Cloud offers two cluster types:

Sandbox clusters are free and last 14 days. They are the right choice for trying something out, running a proof of concept, or testing a new configuration before applying it to a real environment. When the 14 days expire, the cluster and all its data are deleted.

Shared Cloud clusters are paid and persistent. They support high availability configuration, which runs multiple replicas to ensure that a single node failure does not take your search offline.

Both types let you configure auto schema generation (whether Weaviate infers your data schema automatically or requires explicit schema definitions) and CORS origins (which domains are allowed to make requests to the cluster directly from a browser).

A Quick Reference for Daily Tasks

When the Console Is Not Enough

The console handles the operational surface well but has limits. Bulk data operations, automated key rotation as part of a deployment pipeline, programmatic role management, and anything that needs to happen on a schedule all require the API or client library. The console is the right tool for visibility and manual administration — when the task is repetitive or needs to be triggered by code, move it out of the UI.

Knowing what belongs in each layer keeps administration clean. The console tells you what is happening. The API changes it programmatically. Neither replaces the other.