Search that is filtered inside the probe, not after it.
Vector, text and graph search are specified as operators of the same plan language the verifier already checks. The access filter is part of the probe; a candidate the requester may not see is never scored. None of these engines is built.
Planned, not built Planned
| Phase | P6, after distribution (P4) and the first hosted tenant (P5) |
|---|---|
| Benchmark | ANN-Benchmarks and the big-ann filtered track; BEIR for text quality; LDBC Social Network Benchmark (Interactive) for graph |
| Compared with | hnswlib, FAISS, pgvector; Elasticsearch / OpenSearch; Neo4j, TigerGraph |
| Gate | recall@20 ≥ 0.95 at or above their queries per second, with access filters applied; text quality at or above and latency at or below; LDBC validation passed |
Planned, not built. Nothing on this page exists as running code. The specification and the roadmap say what it will be and how it will be measured; no number will be published for it until it is measured on a dedicated benchmark host against the named systems.
What the specification already says
These items are written down in the architecture specification and the plan language, reviewed, and will be built as written or revised in the open.
Filtered vector search
Tenant and access predicates are applied during index traversal, never as a post-filter. The operator declares its recall target (recall ≥ r) and the plan's result class follows from it.
PlannedPer-tenant index partitions
The tenant boundary is strict for every index: no traversal crosses tenants. Above the confidential class, transit through unauthorised entries is forbidden as well; below it, the residual channel is declared and bounded.
PlannedText search
Top-k BM25 over immutable segments, with language analysers including Indic scripts and typo tolerance; segments are partitioned per tenant so filters cut whole segments.
PlannedGraph traversal
Edges are first-class rows, so they get transactions and change capture for free. Depth, fan-out and node budgets are mandatory; an unbounded traversal is rejected at plan time.
PlannedHybrid fusion
Reciprocal-rank fusion of text, vector and graph candidates, each branch carrying its own filters, with a cap on candidates.
PlannedMulti-version embeddings
Two embedding versions can coexist with routing by policy, so a model change does not require a cut-over.
PlannedOperators behind the same verifier
The plan language that every SQL statement compiles to already lists these operators. When the engine arrives, it arrives behind the check that tenant isolation and access filters are applied on every data access.
| Operator | What it is specified to do |
|---|---|
VECTOR_SEARCH(c, v, k, metric, filter, r) | Rows with distance; approximate with a declared recall r; filter applied in traversal. |
TEXT_SEARCH(c, q, k) | Documents with score; access filter pushed into the posting probe. |
GRAPH_TRAVERSE(start, edges, depth, fanout, nodes) | Paths within caps; per-hop access filter. |
Search and vector families | PREFIX, FUZZY, FACET; vector FILTER, FUSION and RERANK are listed operator families in the specification. |
One security model. The roadmap's rule is that every read, whatever the engine, compiles to the plan language and passes the verifier. No side door for a new engine.
What carries this workload now
Built parts that serve the need until the engine exists, and the parts that do not exist yet.
The verifier
The rule that every data access on a tenant-scoped collection is isolated, filtered and masked already names the three probe operators, so the engines arrive behind an existing check.
BuiltExact scans
Until the engines exist, similarity or text matching runs as an ordinary filtered scan in SQL, with the SQL subset's limits.
BuiltIndex-probe tests
The noninterference tests for probe operators and the declared-leakage register are part of the P6 gate, not of today's campaign.
PlannedStraight answers
Is there a vector type or an index I can create today?
No. The operators are specified and the verifier rule names them, but no vector, text or graph index exists in the repository. Any statement that needs one fails with SQLSTATE 0A000.
Why specify the filter inside the probe?
A post-filter over an unfiltered candidate set both loses recall and lets unauthorised entries influence the result. The specification requires the access predicate during traversal and forbids the reverse rewrite.
Follow the gate, not the promise.
The status page lists each phase, its gate and the measurement behind it, and the updates page records each step as it lands.