Vector DB Standards

Vector database standards (the engine as infrastructure)

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

Applies when you have to deploy, operate, size, back up, scale, secure or pay for a vector search engine: the decision of whether a dedicated engine is needed at all, the recall/latency/memory trade-off as an explicit decision, the RAM cost and build time of each index family, pre-/post-filtering, index persistence and backup, rebuilding, deletion and graph degradation, replicas and partitioning, multi-tenancy, and the uses of vector similarity that are not RAG.

Triggers: "do I need a vector database?", "it doesn't fit in memory", "how much RAM does the index need", "binary/scalar/product quantisation", "compress vectors", "collection snapshot", "restore an index", "how long does a rebuild take", "cold start", "the engine takes ages to come up", "replication factor", "collection sharding", "deletion and compaction", "tombstones", "recall dropped when I added a filter", "the filter returns fewer results than I ask for", "isolation by collection or by filter", "one tenant per collection", "endpoint with no authentication", service.api_key, AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED, authorizationEnabled, ports 6333/6334, 19530, 8080, 8000, "embedding inversion", "deduplication", "record linkage", "image search", "anomaly detection", "clustering", "similarity-based recommendation".

Domain thesis: a vector engine is a database that lives in RAM and answers with approximations. The two halves of that sentence decide everything else: memory is the dominant resource and the real cost, and recall is not a fact, it is a parameter you have chosen — consciously or unconsciously.

Arbitration rule with rag-standards (read it before writing anything in this domain): if the question changes what is retrieved, it belongs to rag-standards; if it changes who operates, pays for, backs up or restores the engine, it belongs here. Operational corollary: raising ef_search to improve the recall of a RAG belongs to rag-standards; the node that runs out of RAM building that index, or the restore that takes six hours, belongs here.

Not applicable:

• rag-standards — the critical boundary. It is the retrieval pattern for feeding an LLM: chunking, choice and lifecycle of the embedding model and its reindexing cost, choosing between pgvector and a dedicated engine from the perspective of retrieval quality, HNSW and IVFFlat tuning parameters (m, ef_construction, ef_search, lists, probes), hybrid dense + BM25 retrieval with RRF fusion, cross-encoder reranking, metadata filtering as a retrieval technique, recall@k/MRR/nDCG metrics, and per-document access control in retrieval. None of that is repeated here: when this skill needs those concepts, it links to them. Here, the engine as a piece of infrastructure and the non-RAG uses.
• data-platform-standards — parent skill: the PostgreSQL engine (modelling, migrations, replicas, PITR, tuning, RLS, JSONB, full-text) and the guiding principle "one store per need, not per fashion", which this skill inherits whole. Three-way arbitration for pgvector: the extension and its index parameters belong to rag-standards; the PostgreSQL that hosts it, its backup, its HA and its patching belong to data-platform-standards; the criteria for when pgvector stops being enough and what it costs to operate the dedicated piece that replaces it belong here (§2.2).
• search-engines-standards — text engines (Elasticsearch/OpenSearch, Meilisearch, Typesense, Vespa, Solr), inverted index modelling, BM25 relevance, index lifecycle and cluster operation. Several of them also do vector search: if the engine is already deployed for its lexical capability, the criteria for operating it are theirs; if it is deployed for the vectors, they belong here. Hybrid search crosses all three skills: the fusion criteria live in rag-standards (RRF) for the RAG case and in search-engines-standards for the implementation inside the text engine. Fusion is not decided here.
• nosql-standards, graph-db-standards, timeseries-db-standards, data-warehouse-modeling-standards, lakehouse-standards, streaming-cdc-standards, data-governance-quality-standards, analytics-bi-standards, caching-cdn-standards, message-brokers-standards, oracle-dba-standards, sqlserver-dba-standards, mysql-mariadb-dba-standards: their engines.
• data-engineering-standards: the pipeline that feeds the index (orchestration, idempotent backfill, watermarks). Here only the destination and its write cost.
• privacy-engineering-standards: personal data, minimisation, DPIA, right to erasure. An embedding of personal data is personal data (§5.3): here the technical risk of inversion and the mechanics of deletion in the engine, there the right and its scope.
• llm-app-engineering-standards, mlops-standards, local-inference-standards: the model that produces the vectors, its serving and its lifecycle. Here only what its output costs to store.
• object-storage-standards: S3/MinIO/Ceph as a snapshot destination and as the data layer of the engines that separate compute from storage.
• backup-recovery-standards (backup mechanics, proven restore, immutable repositories) and bcdr-standards (RTO/RPO derived from the business). Here only what is particular about backing up an ANN index.
• kubernetes-standards (StatefulSets, PVCs, operators), linux-storage-standards (the block layer under the engine), iac-standards, cicd-standards, sre-practice-standards (SLOs, capacity planning).
• identity-access-management-standards (the authorisation model), secrets-management-standards (the engine's API key), cryptography-pki-standards (TLS), firewall-policy-standards (whether to expose the port — §5.1), networking-standards, vulnerability-management-standards (CVEs and EOL), grc-compliance-standards.
• aws-standards / azure-standards / gcp-standards: managed equivalents. The sizing and filtering criteria apply the same; the bill and the service model are theirs.
• Language skills (python-standards, typescript-standards, go-standards, …): the clients.

2. Default decisions

Verify version, licence and status on the web before committing to anything (§8). A sector with frequent licence changes and acquisitions; what is verified here is as of August 2026.

2.1 What is this really for? The non-RAG uses

RAG has eaten the conversation, but similarity search is older and broader. Each use has a different operational profile, and the profile decides the engine far more than fashion does:

Criteria: if the use is offline and batch, an in-process ANN library (FAISS, usearch, hnswlib) or a columnar file such as Lance solves it without operating a service. A service is justified by concurrency, online updates and multi-client access, not by having vectors.

2.2 Dedicated engine or pgvector? — the honest question

Inherited from data-platform-standards: one store per need, not per fashion.

The exact threshold is not quoted, it is measured. It depends on dimensionality, quantisation, filter selectivity, available RAM and target latency — any specific figure you read is someone else's experiment. Method: load a representative sample (≥10 % of the target corpus), build the index, measure resident RAM, p95 latency with real filters and build time, and extrapolate linearly in number of vectors (index memory scales that way; latency, better than linearly). If the extrapolation does not fit the budget, you have your answer and you have the ADR.

2.3 Engines — verified status (August 2026)

Vetoed without an ADR: adopting a dedicated engine when you have PostgreSQL and moderate volume; deploying an engine whose licence you have not read this quarter.

2.4 Index families — what decides a deployment

Tuning parameters and their effect on recall belong to rag-standards §2.3. Here only what infrastructure pays for: memory and build time.

Sizing rules that are always forgotten:

1. Budget RAM for two indexes, not one: rebuilding without downtime requires the new one to coexist with the old one. If the node only holds one, you have no hot-rebuild path.
2. Build time is either an unavailability window or a double cost. Measure it before committing to a freshness SLA.
3. Dimensionality is paid linearly in everything: storage, index memory, bandwidth and comparison latency. Reducing it (Matryoshka, PQ) is usually the most profitable cost optimisation — the choice of model and its dimension belongs to rag-standards §2.4.

2.5 Quantisation — the cost lever

Verified as of Aug 2026, per engine (§8):

Hard rules:

• Quantisation is approximation on top of approximation. An ANN index already costs recall; compressing costs more. Measure recall before and after against brute force (method in rag-standards §2.3) — never enable it "for efficiency" without the measurement.
• Rescoring with full vectors is what makes aggressive quantisation usable: search compressed, reorder the candidates at full precision. If your engine supports it, enable it; if it does not support it, aggressive binary is usually unacceptable.
• Compression factors come from the engine's documentation; the impact on recall comes from your corpus. The recall numbers vendors publish are measured on academic datasets with benign distributions. They are not your corpus.

3. The filtering problem — the section that prevents the incident

It is the most common production failure in this domain and it is almost never seen coming, because it does not raise an error: in development, with 10,000 vectors and no filters, everything works; in production, with selective filters, the system returns worse results or takes an order of magnitude longer.

The ANN index is built over all of the vector space. A metadata filter (tenant, date, language, permissions, category) breaks that premise. There are three strategies and all three fail differently:

Criteria:

1. Know which of the three your engine implements and under what conditions it switches from one to another. Many engines have heuristics based on estimated selectivity: below a threshold they do one thing, above it another. That threshold is configurable and almost nobody touches it.
2. Measure recall with the filter applied, not without it. 98 % recall without a filter and 40 % with tenant_id = X is a broken system that passes every test.
3. Index the filter fields. A filter with no payload index forces the engine to evaluate condition by condition during traversal.
4. Ultra-selective filters (a small tenant, a specific user) are almost always resolved better with exact search over the subset than with ANN. If the engine does not decide it by itself, decide it yourself.
5. A filter whose selectivity varies a lot between tenants is a latency bomb: p99 will be set by the worst tenant. Measure per tenant, not in aggregate.

Metadata filtering as a retrieval technique in RAG belongs to rag-standards. Here its consequence on the index, latency and recall.

4. Quality and gates

Gate 6 is the one that saves you most often. A vector engine with an anonymous curl that returns 200 is a data leak, not a configuration issue.

5. Security

5.1 These engines ship open — verified per engine

The most valuable security fact in this skill. Verified in the official documentation as of Aug 2026:

Rules:

• No vector engine is exposed to the Internet. Ever. There is no legitimate use case for a port 6333, 19530, 8080 or 8000 of a vector engine reachable from outside. Private network, and a default-deny firewall rule (firewall-policy-standards).
• Public research (Orca Security, May 2026) documents exposed instances enumerable without authentication on those default ports, with entire corpora —tickets, knowledge bases, conversations— accessible. The exact number of instances is not pinned here (§8): what decides is that the pattern is confirmed and automated.
• The API key is a secret: secrets-management-standards. Not in docker-compose.yml, not in the chart, not in the image.
• TLS mandatory inside the perimeter too (cryptography-pki-standards): the vectors and the payloads travel in the clear otherwise.
• The metrics endpoint and the web panel are also exposed. Count them when opening ports.

5.2 Multi-tenancy: isolation by collection versus isolation by filter

Criteria: if isolation is a regulatory or contractual requirement, separate collection. A filter is a condition that an if can skip; a collection is a boundary. If you choose a filter, the filter is injected in a layer the application cannot go around, and gate 7 of §4 proves it in CI. Per-document access control inside a RAG belongs to rag-standards §5.1.

5.3 Embedding inversion — the specific privacy risk

An embedding is not a hash nor an anonymisation. Inversion attacks exist that reconstruct the original text fully or partially from the vector, and membership inference attacks that reveal whether a document was in the corpus.

Operational, not theoretical, consequences:

• A vector derived from personal data is personal data: it enters the record of processing, classification, retention and the right to erasure (privacy-engineering-standards).
• Do not export vectors to third parties or to lower-trust environments "because they are just numbers". A dump of embeddings is a dump of content.
• Deleting the source without deleting the vector is not deletion (§6.3).
• Minimise before vectorising: what does not enter the corpus cannot be reconstructed.

5.4 Attack surface and supply chain

• The engine enters the patching cycle like any other database. Verified precedents: Milvus CVE-2025-64513, complete authentication bypass in the Proxy component exploitable unauthenticated, with full administrative access; fixed in 2.4.24 / 2.5.21 / 2.6.5. pgvector 0.8.2 (Feb 2026) fixed CVE-2026-3172 (parallel HNSW index builds).
• Indirect risk through integrations: CVE-2026-24477 leaked the Qdrant API key in the clear to unauthenticated users through an AnythingLLM endpoint. Your engine's key can be leaked by any piece that uses it.
• Pin the image by digest, not by tag; SBOM and signing (cicd-standards, vulnerability-management-standards).

6. Operation

6.1 Persistence and durability — verify it, do not assume it

Several of these engines were born in memory only or with optional persistence and added durability later. Before putting in data you cannot regenerate, answer in writing:

1. What is persisted: the vectors, the index, or both? Many engines persist the vectors and rebuild the index at startup — that is the cold start (§6.5).
2. Is there a write-ahead log? What is lost on a SIGKILL?
3. Is the write a synchronous fsync or deferred? Configurable?
4. What consistency guarantee is there between replicas, and what do you see during a node failure?

Golden rule that saves half of these questions: the vector index is a derived projection, not the source of truth. The original text, the metadata and —if you can afford it— the vectors live in a durable store (PostgreSQL, object storage). That way, the worst case for the vector engine is reindexing, not losing data. Design for that from day one and half of this section stops being critical.

6.2 Backup and restore

• A snapshot of an ANN index is not a pg_dump. It is usually a consistent copy of binary segments coupled to the engine version: restoring it on a different version can fail or degrade silently. Record the version with the snapshot.
• A hot disk snapshot taken without coordinating with the engine can be inconsistent. Use the engine's own snapshot mechanism, or freeze writes (fsfreeze and hooks: backup-recovery-standards).
• The real cost of the backup is the restore, and restoring a large index includes loading it into memory. Time it (§4, gate 4) and compare it against the committed RTO (bcdr-standards). It is common for reindexing from the source of truth to be faster than restoring — if that is your case, that is your recovery procedure and it has to be written down.
• Destination: object storage with versioning and immutability (object-storage-standards), client-side encrypted.

6.3 Updates, deletions and compaction

• Graph indexes degrade with deletion. The usual pattern is to mark (tombstone) and compact later: between the two, the index occupies memory for vectors that no longer exist and traversal passes through dead nodes. Recall and latency get worse over time in a corpus with high turnover.
• Compaction is I/O and CPU intensive: schedule it, observe it and account for its peak. A very volatile corpus may need periodic rebuilding, not just compaction.
• Updating a vector = delete + insert in almost every engine. Reindexing the same document repeatedly inflates the index even though the logical number of records does not change. Watch logical vectors versus physical vectors: if they diverge much, it is time to compact or rebuild.
• In IVF, the distribution changes and the centroids age: recall drops even though nothing fails. Retraining is a planned operation.
• Deletion and the right to erasure: the deletion must reach the vector, the index, the replicas, the current snapshots and any cache. A deleted=true that a filter can forget is not a deletion (privacy-engineering-standards; mechanics in RAG: rag-standards §6.2).

6.4 Scale

• Read replicas are the easy lever: the load on these systems is usually overwhelmingly read. They cost full memory per replica — the index is not shared.
• Partitioning (sharding): splits the corpus. Each query goes to all the shards and is merged, so p99 is set by the slowest shard and adding shards does not reduce latency, only memory per node. Partition for memory, not for latency.
• Partitioning by a business key (tenant, language, date) is better than partitioning at random if the queries carry that key: then the query touches one shard and latency does improve. It is the design decision with the highest return in this section.
• When the index stops fitting in memory there are exactly four ways out, in order of increasing cost: (1) quantise (§2.5), (2) reduce dimensionality, (3) on-disk index over NVMe, (4) partition horizontally. Buying RAM is the fifth and not always the worst.
• Rebalancing: moving a shard is moving gigabytes and rebuilding an index. Ask before deploying how long it takes and whether it can be done without downtime.

6.5 Cold start

The startup time of a vector engine is not that of a process, it is that of loading tens or hundreds of GB into memory (or rebuilding the index, per §6.1). Consequences that break deployments:

• Liveness/readiness probes with web-service thresholds kill the pod in a loop (kubernetes-standards): tune startupProbe.
• A rolling restart of N replicas costs N × startup time, with reduced capacity meanwhile.
• Reactive autoscaling does not work with this profile: by the time the new replica is ready, the peak has passed. Over-provision or scale on an anticipatory signal.
• Measure it and put it in the runbook. It is the number nobody has when it is needed.

6.6 Cost and observability

Memory is the dominant cost, and it rises through three multiplying paths: number of vectors × dimensionality × replicas. The levers, by return: quantisation → dimensionality → number of replicas → on-disk index.

Instrument (observability-standards covers the transport and the backend):

• Resident RAM of the process versus node RAM — the metric that predicts the outage.
• p50/p95/p99 latency per collection and per tenant, not in aggregate.
• Logical versus physical vectors (compaction debt).
• Write rate, indexing lag, compaction duration.
• Recall measured periodically against brute force over a sample: it is the only alarm that detects silent degradation. Without it, an index that gets worse produces no signal at all.
• Cold start time and index build time, as historical series.

6.7 Minimum runbook

Index that does not fit in memory (node OOM); latency spiking after adding a filter; recall that drops with no code change (pending compaction, aged centroids, corpus drift); snapshot that does not restore on the current version; node that never finishes starting; tenant that sees another's data (security incident, not a bug: incident-management-standards, incident-response-forensics-standards); engine discovered exposed without authentication (assume compromise and treat the corpus as leaked).

7. Sustainability and prohibitions

Review cadence: 3 months. Versions, licences, quantisation methods and CVEs move quarterly in this sector.

• Review: engine version and CVEs, licence (frequent change pattern), new quantisation support (methods with a better trade-off appear every few months), and whether the memory budget still matches the real growth of the corpus.
• Updating the engine may require rebuilding the index or invalidate snapshots. Read it in the release notes beforehand, not during.
• Recorded conscious debt: recall not measured, restore not proven, pending compaction, postponed authentication ("it's only on the internal network").

FORBIDDEN

• ❌ Deploying a dedicated vector engine when you have PostgreSQL and moderate volume, without an ADR.
• ❌ Deploying a service for an offline batch use that an in-process ANN library would solve.
• ❌ Exposing the engine's port to the Internet. Under no circumstances.
• ❌ Starting up in any network-reachable environment without authentication or TLS (§5.1). "It's on the internal network" is not a control.
• ❌ Leaving Milvus's default password (root/Milvus) or any demo credential.
• ❌ Putting the engine's API key in the docker-compose.yml, the chart or the image.
• ❌ Pinning index parameters or enabling quantisation without measuring recall against brute force.
• ❌ Measuring recall without the production filters applied and declaring the system good.
• ❌ Trusting post-filtering with selective filters and not noticing that you return fewer than k.
• ❌ Filtering by a field without a payload index.
• ❌ Sizing RAM for a single index and being left with no hot-rebuild path.
• ❌ Treating the vector index as the source of truth, with no durable source to reindex from.
• ❌ Snapshot without a proven restore and without timing it; snapshot without recording the engine version.
• ❌ Copying the disk hot without using the engine's snapshot mechanism or freezing writes.
• ❌ Ignoring graph degradation from deletion in a corpus with high turnover.
• ❌ Logical deletion as an answer to a right to erasure.
• ❌ Treating an embedding as anonymisation, or exporting it to a lower-trust environment.
• ❌ Multi-tenancy by filter when isolation is a regulatory requirement, or without an isolation test in CI.
• ❌ Startup probes with web-service thresholds over an engine that loads GB into memory.
• ❌ Reactive autoscaling as the capacity plan of an engine with a long cold start.
• ❌ Chroma in serious production; adopting Milvus 3.x without reading the migration guide.
• ❌ Duplicating rag-standards criteria here (chunking, embeddings, ANN tuning, hybrid, RRF, reranking, recall@k) instead of linking to them.
• ❌ Pinning a version, a licence, a compression factor or a recall figure from memory (§8).

8. Mandatory web verification

1. Version and licence of each engine: pgvector, Qdrant, Weaviate, Milvus, Chroma, LanceDB. Verified as of Aug 2026 via release Atom feeds and the repository's LICENSE files (not via summaries of HTML pages, which invent dates): pgvector 0.8.6 / PostgreSQL licence; Qdrant 1.18.3 / Apache-2.0; Weaviate 1.38.8 and 1.39.0-rc.1 / BSD-3-Clause confirmed in the core's LICENSE; Milvus 3.0.0 and 2.6.22 / Apache-2.0; Chroma / Apache-2.0; LanceDB 0.36-0.37.x / Apache-2.0. Re-verify: licence change is the sector's pattern.
2. CVEs: Milvus CVE-2025-64513 (unauthenticated auth bypass, fixed in 2.4.24/2.5.21/ 2.6.5), pgvector CVE-2026-3172 (fixed in 0.8.2), CVE-2026-24477 (leak of the Qdrant API key via AnythingLLM). Check for new advisories before pinning a version.
3. Default authentication per engine (§5.1). Verified verbatim in official documentation for Qdrant, Weaviate and Milvus. Re-verify it on every major version: it is the fact that changes most and the one that costs most if it is wrong.
4. Quantisation support per engine and version (§2.5), and whether there is rescoring with full vectors.
5. Persistence model of the specific engine (§6.1): what is persisted, WAL, fsync, and whether the index is rebuilt at startup.
6. Snapshot compatibility between versions before any update.
7. Equivalent managed services and their pricing model (aws-standards, azure-standards, gcp-standards) — they change often.
8. Supply-chain incidents in the ecosystem (precedents in the catalogue: LiteLLM on PyPI, March 2026).

Declared gaps — do NOT fill in from memory:

• Exact volume threshold at which pgvector stops being enough: deliberately not pinned. It depends on dimensionality, quantisation, filter selectivity, RAM and target latency. It is measured with the method of §2.2.
• Memory consumption formulas per index family: not pinned. The ones in circulation omit the real overhead of the graph and the payload. Measure it over a sample.
• Impact on recall of each quantisation method: not pinned. The compression factors come from the vendor's documentation (verified); recall depends on your corpus and your model.
• Quantisation in Milvus 3.x: not verified in detail in this review (the major is from Jul 2026). Consult its documentation before pinning anything.
• Default auth status of Chroma and LanceDB: verified only indirectly (Chroma without auth in the standard startup, port 8000; embedded LanceDB exposes no service). Confirm it in their documentation before deploying.
• Figures for instances exposed on the Internet: the pattern is confirmed by public research (Orca Security, May 2026); the specific counts circulating in blogs are not quoted as facts.
• Latencies, throughput and comparative benchmarks between engines: not pinned. The public ones are almost always from vendors, without reproducible conditions and over academic datasets.
• Prices of the managed services: not pinned.

If the web contradicts this document, the web wins — flag the discrepancy.