If you search for “vector database hub” or “vector console” or “vector app,” you are probably looking for the same thing: a browser interface where you can manage your vector database without writing code. The fact that people use so many different terms for this is not a sign of confusion on their part — it is a sign that the vector database ecosystem has not settled on a standard vocabulary.
Understanding why the terminology fragments the way it does helps you navigate documentation, find what you are looking for faster, and avoid assuming that different terms mean different products.
Why Naming in This Space Is Inconsistent
The vector database ecosystem is relatively young, and it grew out of several different traditions simultaneously. Researchers came from machine learning, where the relevant concept was an embedding store or a similarity search index. Developers came from document databases and search engines, where the interface was called a dashboard or an admin console. Infrastructure engineers came from cloud platforms, where it was called a control plane or a management console.
None of these groups adopted a shared term, so the naming in the space reflects all of them at once. “Vector database” itself is not universally agreed upon — some platforms call themselves vector search engines, embedding databases, or AI-native databases. The admin interface inherits the same fragmentation. One platform calls it an app. Another calls it a console. Another calls it a hub or a workspace or a control panel.
From a user’s perspective, these all describe the same functional thing: a place to see what is in your database, manage who has access, and run queries interactively.
The Background Expectations Users Bring
The specific terms people search for often reflect the tools they came from.
Users coming from traditional databases tend to search for “app” or “admin tool” — they are looking for something like pgAdmin for PostgreSQL or MongoDB Compass. Those tools are standalone desktop or browser applications, and users expect an equivalent for vector databases.
Users coming from SaaS platforms tend to search for “hub” or “workspace” — they expect a multi-resource dashboard where everything related to their account lives in one place, similar to a cloud provider console.
Users coming from other vector databases look for the equivalent of whatever their previous platform called it. Milvus users, for instance, know Attu — an open-source GUI for Milvus administration. When they switch to a different vector database, they search for “vector database admin console” expecting something comparable.
All of these searches point toward the same type of interface: a GUI for human-driven administration.
Self-Hosted Deployments Add Another Layer
The terminology confusion deepens for self-hosted deployments. Managed cloud platforms provide a console as part of the service. Self-hosted instances — running in Docker or on Kubernetes — do not always come with an equivalent GUI maintained by the vendor. Users running self-hosted setups who search for an admin interface sometimes discover they need to build one, use a third-party tool, or administer everything through the API.
This creates a divide in search intent that the same terms cover. Someone searching for “vector database console” might want the cloud dashboard for a managed service, or they might want a GUI for their self-hosted Docker instance. The answer is different in each case, which is part of why documentation often feels like it does not quite answer the question being asked.
Weaviate: One Console, Multiple Search Terms
In Weaviate’s case, the destination for all of these searches is the same place: the Weaviate Cloud console at console.weaviate.cloud. Whether someone searches for “Weaviate hub,” “Weaviate app,” “Weaviate console,” or “Weaviate admin panel,” they are looking for this interface.
The console covers the full range of things an admin dashboard is expected to do:
- Cluster administration: create, monitor, and delete clusters
- Access management: issue and revoke API keys, create and assign RBAC roles
- Interactive querying: a built-in GraphQL IDE with syntax highlighting, type-ahead, and real-time error reporting
- Metrics: query latency, ingestion throughput, object count, and batch size dashboards
The GraphQL IDE is worth highlighting specifically because it is the feature most analogous to what users are picturing when they search for a “vector database app.” It lets you run queries directly in the browser, inspect results, and verify that your data and schema look correct — the kind of interactive exploration that traditionally requires either a dedicated client application or writing query scripts.
The Self-Hosted Caveat
The full admin experience — key management, role management, metrics dashboards — is only available for Weaviate Cloud deployments. For self-hosted instances running in Docker or Kubernetes, the Weaviate Cloud console can connect as an external cluster to run GraphQL queries, but the richer administrative features are cloud-only.
For teams that need a GUI for a self-hosted Weaviate instance, an open-source third-party tool called WeavyAdmin provides a desktop alternative. It is not an official Weaviate product, but it fills the same role that pgAdmin fills for PostgreSQL — a standalone GUI for people who prefer not to administer everything through the API.
What This Means Practically
If you are trying to find the right interface and the documentation is using a term you do not recognize, the safest assumption is that the console, the app, the hub, and the dashboard all refer to the same thing. Vector database platforms generally have one primary GUI, and whatever they call it is the interface you are looking for.
The more meaningful distinction is not in the name but in the deployment model: cloud-managed deployments typically have a richer GUI experience because the vendor controls the full stack. Self-hosted deployments give you more control but often less out-of-the-box tooling for administration.
Knowing which situation you are in — managed cloud or self-hosted — is more useful for finding what you need than knowing the exact term any given platform uses for its interface.