Vector databases
A vector database holds a tenant’s knowledge collections. Each one belongs to one tenant. Admins and Builders create them; everyone who can open Knowledge can see their health, usage and backups.
How a database is hosted depends on how Olympusx AI was installed:
- Dedicated: each vector database is a database server of its own, with its own pods, storage, credentials and failure domain, on a cluster and in a namespace you choose. This is the default on a Kubernetes, OpenShift or OKE installation.
- Shared: each vector database is a database on one shared vector store. There is nothing to place, size or back up per database. This suits an evaluation.
The Provider column and the database’s page tell you which one a database uses.
Who can open it
Section titled “Who can open it”| Role | What they can do |
|---|---|
| Admin | Create, delete, and change a database’s backup settings. |
| Builder | The same as an Admin. |
| Auditor | Open the list and every database page and read them. Cannot create, change or delete. |
| Reviewer | Cannot open it. |
| End user | Cannot open it. |
| Platform admin | Everything an Admin can, for any tenant, and may also place a database in a new namespace or in any namespace that does not belong to another tenant. |
What you see
Section titled “What you see”The list
Section titled “The list”Open Build › Knowledge, then the Vector databases tab. It shows a search box, Create vector database for Admins and Builders, and one row per database:
| Column | What it shows |
|---|---|
| Name | The database’s name, which opens its page, whatever its status. |
| Status | Provisioning, Ready, Failed or Deleting. The list refreshes itself while a database is provisioning or deleting. |
| Collections | How many collections it holds. Opens the Collections tab filtered to this database. |
| Provider | How it is hosted: dedicated or shared. |
| Namespace | The namespace it runs in. Empty on a shared store. |
| Size | Small, Medium, Large or Custom, its CPU, memory and storage, and HA ×3 when it is highly available. |
| Created | When it was created. |
| Actions | Delete vector database, for Admins and Builders. |
When the tenant has none, the list says No vector databases yet with Create vector database.
A database’s page
Section titled “A database’s page”The header shows the name, its status and Refresh. A failed database shows Provisioning failed with the reason. If the latest read fails, the page keeps what it read last and says when.
The page has four tabs:
| Tab | What it holds |
|---|---|
| Overview | Four figures (Instances ready, Collections, Data stored, Write-ahead log), then Placement and size, Storage, CPU and memory, Write-ahead log and archiving, and Backups. |
| Collections (n) | The collections in this database. When there are none: “Create one from the Collections tab of Knowledge.” |
| Pods | Each pod of the database: Pod, Role (Primary, Replica or Job), Status, Restarts, CPU, cores, Memory, Node, Started. |
| Events | What the cluster reported about the database, its pods and its volumes, newest first: Type, Reason, Object, Count, Last seen. The cluster keeps events for about an hour. |
On the Overview tab:
- Placement and size: Provider, Cluster, Namespace, the database cluster’s name, its Phase, which pod is Primary, Size, Created and Last read.
- Storage, CPU and memory: storage used of the volume per instance, and CPU and memory per pod against what each pod was given. On a shared store this says the database shares a server, so there is no volume or quota of its own to measure against.
- Write-ahead log and archiving: whether the log is being archived, its size on disk, segments, segments waiting to be archived, failed archive attempts, and when the last one was archived.
- Backups: Recoverability (“Recoverable to any point since time”, or “Not recoverable yet: no base backup has completed”), the last successful and failed backups, and, for Admins and Builders on a dedicated database, the backup controls.
Rows that do not apply to a shared store say Does not apply here.
What you can do
Section titled “What you can do”Create a vector database
Section titled “Create a vector database”- Open Build › Knowledge › Vector databases and choose Create vector database.
- Basics: enter a Name, up to 60 characters and unique in the tenant.
- Placement (dedicated only):
- Host cluster: the cluster that runs the database. The list holds the clusters your tenant holds capacity on that can host one. When none can, the step says This tenant holds no capacity on a cluster (ask a platform admin to grant capacity) or No cluster can host a database.
- Namespace: the namespace whose permissions, quota and network rules apply to the database. Leave it unchosen to use the platform’s shared vector database namespace, or pick one of your tenant’s namespaces. A platform admin can also tick Create a new namespace and enter its name.
- Size and availability (dedicated only):
- Size: Small, Medium, Large or Custom (see the table below). For Custom, enter CPU (cores), Memory (GiB) and Storage (GiB).
- Highly available: three replicas instead of one, so the database survives losing a node and fails over on its own. It costs three times the CPU, memory and disk.
- The step shows Capacity on cluster: what the tenant holds, what is already in use, and what this database needs. Next stops when the database does not fit.
- Backups (dedicated only): turn Back up this database on or off, and set Keep backups for (days) and Daily base backup at (UTC). When the platform has no backup destination, the step says Backups are not available yet.
- Review: check the name, cluster, namespace, size, availability and backups, then choose Create vector database.
Olympusx AI opens the new database’s page. A dedicated database takes a few minutes to start; its status moves from Provisioning to Ready, and the Events tab says what it is waiting for. On a shared store the wizard has only Basics and Review.
Choose a size
Section titled “Choose a size”| Size | CPU | Memory | Storage, per replica |
|---|---|---|---|
| Small | 2 vCPU | 2 GiB | 10 GiB |
| Medium (default) | 4 vCPU | 4 GiB | 20 GiB |
| Large | 8 vCPU | 16 GiB | 64 GiB |
| Custom | Up to 128 cores; a fraction such as 0.5 is half a core | At least 0.5 GiB | At least 1 GiB |
Medium is the shape the platform runs its own database at. A custom size is reserved as well as capped, so the database is not the first thing evicted when its node runs short. Storage also holds the write-ahead log; plan roughly 10 KiB per stored chunk and leave headroom. A vector index that does not fit in memory turns every search into disk reads.
The size is set when the database is created.
How a database counts against capacity
Section titled “How a database counts against capacity”A dedicated database counts against the tenant’s capacity on its cluster, the same capacity its CPU model deployments use. It counts at its CPU, memory and storage times its replicas. Every database still listed counts, a failed one included, until you delete it.
- The tenant needs CPU and memory above zero on the cluster.
- A database that would take the tenant over what it holds on the cluster is refused.
A platform admin grants capacity on the tenant’s page. See Tenants.
Change backups
Section titled “Change backups”Backups archive the database’s write-ahead log continuously and take a daily base backup, so the database can be restored to any point within the retention. They go to the platform’s backup destination, which a platform admin sets in Settings; see Backup and restore.
- Open the database and stay on Overview. Under Backups:
- Turn Back up this database on or off.
- Set Keep backups for (days), between 1 and 3,650. The default is 30.
- Set Daily base backup at (UTC) as
HH:MM, for example03:10, the default. - Choose Save backup settings.
Turning backups off asks first: the database stops archiving and taking base backups and cannot be restored to any point after that. Backups already stored stay where they are, and nothing prunes them while backups are off.
The Backups section reports problems in words, for example “Archiving is failing: recovery ends at the last archived segment, and the write-ahead log is filling the volume.”
Delete a vector database
Section titled “Delete a vector database”- On the Vector databases tab, open the row’s Actions menu and choose Delete vector database.
- Type the database’s name to confirm, then choose Delete.
The database is deleted and cannot come back. Olympusx AI refuses while the database still holds collections: delete those first. Deleting a database never deletes the namespace it ran in.
Limits
Section titled “Limits”| What | Limit |
|---|---|
| Database name | Up to 60 characters, unique in the tenant |
| New namespace name | Lowercase letters, digits and dashes, starting and ending with a letter or digit, at most 63 characters |
| Namespaces a tenant may use | The platform’s shared vector database namespace, or a namespace that belongs to the tenant. System namespaces and another tenant’s namespaces are refused. |
| Replicas | 1, or 3 when highly available |
| Custom CPU | Up to 128 cores |
| Custom memory | At least 0.5 GiB |
| Custom storage | At least 1 GiB |
| Backup retention | 1 to 3,650 days; default 30 |
| Base backup time | Daily, HH:MM in UTC; default 03:10 |
| Delete | Refused while the database holds collections |