SABLE is the engine underneath VectorAmp: a filter-native, billion-scale vector index that treats the WHERE clause as a first-class part of the query plan. Built in Rust with AVX-512 kernels, and validated to Recall@10 ≥ 0.95 on a single 1B-vector node.
Single-node results on stock AWS instances. Full methodology, query workloads, and ablations live in the whitepaper.
Four design choices made early — and held to — that compound at scale.
Most vector stores treat metadata filters as a post-processing step that throws away precomputed work. SABLE plans the filter and the ANN graph traversal as a single query — selectivity-aware, with shard-local statistics. Selective filters get faster as your corpus grows, not slower.
Sharding is a first-class concept in SABLE — not a wrapper around per-shard search. The query coordinator routes by metadata keys you specify, prunes shards by filter, and merges with bounded recall guarantees. Add a shard, capacity scales linearly.
SABLE is tuned for the retrieval patterns VectorAmp itself runs on: filtered semantic search, RAG with citations, recommendation, and deduplication. Practical defaults for product workloads, not synthetic-benchmark theater.
Hot paths should stay fast, warm data should be compact, and cold data should not dominate your bill. SABLE is designed around explicit storage tiers and predictable read amplification.
SABLE is a compact cold-tier vector index with filter-aware planning built into the storage layout, not bolted on after retrieval.
Python and TypeScript clients use the same dataset-scoped search API as the platform. Pass text or vectors, top-k, metadata filters, and advanced range filters directly.
# filtered semantic searchfrom vectoramp import VectorAmp
client = VectorAmp(api_key="va_...")dataset = client.datasets.get("dataset_id")
results = dataset.search( text="migration plan risks", top_k=20, filters={"team": "platform", "region": "eu"}, advanced_filters=[{"field": "year", "op": "gte", "value": 2025}], include_documents=True,)// same query, TypeScriptimport { VectorAmp } from "@vectoramp/vectoramp";
const client = new VectorAmp({ apiKey: process.env.VECTORAMP_API_KEY });const dataset = await client.datasets.get("dataset_id");
const results = await dataset.search({ queryText: "migration plan risks", topK: 20, includeMetadata: true, filter: { team: "platform", region: "eu" }});SABLE vs DiskANN on the published whitepaper benchmark: 1M vectors at d=1536 (DBpedia-OpenAI) and 100M vectors at d=96 (Deep-1B per shard). Single-node, p95 latency and Recall@10 against ground truth.
| Filter-nativeSABLE | Disk-resident graphDiskANN | In-memory graphHNSW | |
|---|---|---|---|
| Unfiltered p95 (1M, R@10≈0.94) | 5.1 msnp=16, rerank=4 | 175 msdisk-resident | Fast in-RAMat huge memory cost |
| Filtered p95 (1M, ~11% selectivity) | 14–20 mspredicate pre-gates lists | 132.9 msfilter as post-step | Degrades sharplyfilter masks during traversal |
| Filtered p50 (100M, 10% selectivity) | 24–59 ms28–101× faster than DiskANN | 1.3–3.1 sdisk seeks dominate | Does not fit~640 GB RAM at d=96 |
| Memory @ 1M, d=1536 | 80 MBPQ codes + micrographs | Disk-resident | 25 GBgraph in RAM |
| Memory @ 1B, d=96 | Page cache~448 GB on NVMe, paged on demand | Disk-resident | ~640 GB RAMrequired |
| Recall@10 ceiling | 0.994 → 0.95+ @ 1B | 0.897 (1M) | High, but memory-bound |
Validated single-node ceilings from the whitepaper. Fan out to multiple shards through the coordinator for higher throughput and larger corpora.
Start on managed Cloud today. Enterprise is for teams that need materially higher usage limits and commercial support while we build bring-your-own-cloud for a later release.
Fully managed on AWS. The same SABLE engine that powers the VectorAmp Intelligence Platform, surfaced through the VectorAmp API and SDKs. Trial available without a credit card.
For teams pushing beyond standard plan limits: larger workloads, higher query volume, heavier embedding generation, and commercial terms sized around real utilization. Bring-your-own-cloud is in development, but not available today.
Yes — bit-for-bit. The VectorAmp platform runs on SABLE. Buying SABLE standalone gets you the same engine, the same indexing pipeline, and the same query planner — minus the application layer (canvases, agents, intelligence UI). If you outgrow SABLE-only and want the platform on top, your indexes carry over.
Most vector stores retrieve candidates first, then apply metadata filters afterward. If your filter rejects 90% of candidates, the engine has to over-fetch and hope enough survive. SABLE stores filter metadata alongside each IVF list, estimates per-list selectivity, prunes impossible lists, then chooses the right path — linear ADC scan for selective filters or micrograph beam search for dense/unfiltered lists.
SABLE is the index VectorAmp creates for datasets: an OPQ-rotated IVF-PQ foundation, per-list micrographs for unfiltered traversal, and per-list bitmap plus quantile-sketch pre-gating for filters. We benchmark against systems like HNSW and DiskANN, but we do not expose those as customer-selectable index modes in the current SDKs.
Not today. Current Enterprise plans run on managed VectorAmp Cloud with higher usage limits and commercial support. Bring-your-own-cloud is in development for a later release, but custom Kubernetes or VPC-isolated deployments are not generally available right now.
SABLE is included in the VectorAmp Cloud plans. The trial is free with hard-capped usage; paid plans include monthly vector-query and vector-write allowances with metered usage above them. See the pricing page for the current plan lineup, or contact sales for Enterprise terms.
Stop paying the post-filter tax. Run your filtered workload against the same engine that powers VectorAmp Intelligence.