RFC: vector search support across storage backends

[LeeroyHannigan]

Summary

DynamoDB reached GA with native vector search on 2026-08-05: a new index type created over an attribute holding an embedding, plus a SearchVectors operation returning nearest neighbours ranked by a distance function, with optional exact-match inline filtering.

An application that adopts it cannot use ExtendDB for that workload at all today. CreateTable rejects the unknown index type and SearchVectors is an unknown operation, so local development, CI, and offline or edge deployments lose the ability to exercise the code path.

This RFC proposes adding that surface.

The central design question

The RFC separates what must be identical across backends from what cannot be.

Wire surface, validation, score sign convention, index lifecycle and the consistency model are defined once in the engine. ANN execution is a declared per-backend capability (Ann, ExactScan, Unsupported), because the stores diverge sharply:

• PostgreSQL has pgvector, but only if the operator installed it
• SQLite has sqlite-vec, likewise a loadable extension
• MongoDB has vector search in Atlas, not in community mongod

Mandating ANN everywhere would convert a feature gap into a backend gap. The recommendation is that vector search be optional for backend acceptance, provided a backend that cannot do it fails closed at CreateTable with a typed error rather than returning wrong results later.

Two points that carry most of the risk

Score semantics are asymmetric. Lower is more similar for Cosine and Euclidean (0 is identical); higher is more similar for DotProduct. Normalising all three into one "similarity" number inverts the ranking for two of them. I have seen this exact defect in a first-party client library against the real service, so the RFC asks for the sign convention to be asserted per distance function rather than inferred from result sets.

A vector index is eventually consistent, the same model as a GSI. So the proposal reuses the existing pending-index queue and gsi_propagation_delay_ms rather than adding a second asynchronous mechanism. It also requires that an index must not report ACTIVE while its backfill is still draining, with the transition causally ordered after the drain rather than scheduled on a wall clock beside it.

Testing

Recall is not assertable by equality, so ExactScan is proposed as the oracle (perfect recall) with ANN backends held to a recall threshold against it. Everything deterministic (sign convention, top K truncation, partition-key scoping, filter rejection, lifecycle) is asserted exactly.

What I am asking reviewers for

1. Should vector search be optional for backend acceptance? I propose yes.
2. What recall threshold should ANN backends be held to, and is it a gate or a reported metric?
3. Should ExactScan be reachable in a production configuration at all, or gated?

Five service behaviours are listed as unresolved rather than guessed at, including the dimension-mismatch error on PutItem and whether a missing vector attribute gives sparse-index behaviour. I am happy to verify each against the real service before the corresponding code is written.

Note on numbering: the file is 0000-vector-search.md per the process in docs/rfcs/README.md, which keeps 0000 until acceptance.