Comparison
polign_db is an object-storage-native vector and hybrid search database. This page explains how it compares to turbopuffer, Amazon S3 Vectors, LanceDB, Qdrant, and Milvus.
Vector databases split into three families. We will describe the comparison between the three and where polign_db stands.
Architectural differences
Modern database storage architectures are largely defined by where the data lives and how it is accessed. The distinction falls into three categories: in-memory databases (prioritizing raw performance), embedded libraries (running inside the client application), and cloud-storage-native systems.
The index lives in RAM or on SSD, which may be replicated across nodes for durability.
The database is a library inside the application processes, reading local files. Zero ops, and the right fit for local-first apps and notebooks.
Durability and the source of truth are guaranteed by the underlying object storage.
To conclude on the architecture: turbopuffer operates this object-storage-native model at scale; AWS shipped S3 Vectors; Milvus, Chroma, and Weaviate are retrofitting object-storage tiers onto family-1 engines. polign_db is built this way from the first line of code — the implementation you can read, patch, and run on your own bucket.
The matrix
Every row below is a question with money or shipped features attached — not an architecture checkbox. Rows where every system scores the same are left out, and where a competitor is simply better today, we say so.
| polign_db | turbopuffer | S3 Vectors | LanceDB | Qdrant | Milvus | |
|---|---|---|---|---|---|---|
| What you own | ||||||
| Open source | Yes — one small Go codebase | No closed source | No managed service | Yes | Yes | Yes |
| Your data on your bucket, in your VPC | Yes — any S3-compatible store | Partial vendor-run; BYOC tiers vary | No AWS-managed only | Yes — local files or your S3 | Partial in your VPC, but node-local disks | Partial in your VPC, plus its service stack |
| What you operate | ||||||
| Infrastructure | Minimal one binary + a bucket | None SaaS | None managed | None embedded | Some binaries + Raft cluster at scale | Heavy Kubernetes + etcd + MQ + object store |
| Recovery | Yes — the bucket is the source of truth; a replacement warms on demand | Yes | Yes managed | Depends your files, your backups | Recovers replicas re-sync and rebalance | Recovers re-replication across the cluster |
| Cost | ||||||
| Hold 1 TB for ~$20 / month | Yes — cold-first mode | Close vector storage + usage pricing | Close vector storage + per-request pricing | Yes — on your S3 | No replicated RAM/SSD (~$600–3,000) | No replicated disk tiers |
| Idle data costs | Yes — idle collections pay only storage pricing; queries pay per-download | Yes | Yes | Partial disk you provision | No nodes run either way | No nodes run either way |
| Large corpus | Yes — GET-cost-bound, not RAM-bound | Yes | Yes | Partial disk-bound | No RAM/disk-bound | Partial tiered storage, ops-heavy |
| What a write means | ||||||
| Consistency | Yes — durable-on-ack, per-collection total order, read-your-writes (text freshness is persist-lag) | Partial durability; ordering / read-your-writes unspecified | Partial freshness not contractually specified | Partial managed within single-process | Yes tunable write consistency | Yes tunable levels incl. session |
| What your users get | ||||||
| Hybrid BM25 + vector search | Yes — server-side RRF & linear fusion | Yes | No dense only | Partial in-process, bring a reranker | Partial bring your own sparse vectors | Yes — built-in BM25 |
| Rich metadata filtering | Yes exact match, lists, ranges, and exists, combined with and/or/not — filters run during the search, hot or cold, and stay accurate even when they match few records | Yes exact filters | Basic | Yes SQL predicates | Yes best-in-class filtered HNSW | Yes full expressions |
| Single-digit-ms hot path latency | Warm frequently-queried data is served from RAM; the cold path pays object-storage latency (~144 ms on in-region S3, measured) | Warm cached namespaces | No relaxed-latency tier | Yes in-process | Yes built for it | Yes plus GPU indexes |
| Many small datasets at scale | ||||||
| Thousands of isolated collections | Yes — each collection has its own index and write order in the bucket; idle collections cost only storage | Yes — namespaces at massive scale | Partial index-per-tenant, request-priced | Partial table-per-tenant, embedded | Partial payload partitioning in shared collections | Partial partitions; 100k collections |
// supported partial / depends not available · competitor cells summarize vendor documentation; we link primary sources rather than restate their marketing.
polign_db is the option in this table that is open source, object-storage-native, and hybrid out of the box — and that behaves like a database, by documented contract.
Which one should you choose?
Every system in this table is the right choice for the workload it was built for. Here is where each one wins — including when it isn't us.
Your corpus is large and access is skewed — most data cold, some data hot — and you want hybrid BM25 + dense retrieval out of the box. The shape fits agent memory exactly: thousands of small, mostly-cold collections with read-your-writes, cheap enough to give every user their own. The source of truth sits on your bucket, in your VPC, under your IAM policies, in source you can read and patch. You pay object-storage prices for the 95% of data that's cold, and you never run etcd, Kafka, or a consensus cluster to do it.
Your working set is fully hot and every millisecond of tail latency matters — or you need deep LangChain / LlamaIndex integration. RAM-resident indexes win that race; you pay for the win in replicated-RAM/SSD economics and capacity coupled to compute.
Your database can live inside one process — desktop apps, notebooks, edge, pipelines. An embedded library is the simplest tool for that job; it stops being the tool the day you need concurrent writers or a shared server.
You're all-in on AWS, your workload is pure dense retrieval at relaxed latency, and zero operational surface matters more than relevance. The moment you need BM25, hybrid fusion, or a second cloud, you've outgrown it.
You want exactly this architecture, fully managed, proven at trillion-document scale — and you're comfortable with a closed-source vendor holding your search path. It's the strongest endorsement of the model there is; it just isn't yours to run.
What a terabyte costs
Architecture always surfaces on the bill. A family-1 engine must hold every byte in replicated RAM or SSD whether that byte is queried once a second or once a month — the machine is rented either way. An object-storage engine holds the same byte for cents and pays only when it is read. Per terabyte per month, at list prices:
| Storage tier | ~$ / TB · month | Who serves from it |
|---|---|---|
| Replicated RAM | $3,000+ | family-1 engines at their lowest latency |
| 3× replicated SSD | $600 | family-1 disk tiers |
| Object storage + SSD cache | $70 | polign_db warm path (and turbopuffer) |
| Object storage only | $20 | polign_db cold-first mode |
polign_db serves from the bottom two rows and promotes data upward only when your traffic earns it. These are illustrative list prices for planning, not a benchmark, and the cold path trades a per-GB bill for a per-download one — a search that probes 8 regions of the index makes 8 GETs. The benchmarks page has cold-path latencies against Amazon S3 in the same region (~80–144 ms typical at 84–98% accuracy, measured from an 8-vCPU EC2 instance) and a cost calculator you can put your own numbers into.
We publish numbers only when they're reproducible with the harness in the repo. Measured hot-path, cold-path (latency percentiles with GET counts and bytes per query), and write-path numbers — all from an 8-vCPU EC2 instance against in-region S3 — are on the benchmarks page. In flight: hybrid relevance (nDCG@10 on BEIR / MS MARCO) and sustained end-to-end ingest.
Run it on your bucket this afternoon
One Go binary, one S3-compatible bucket, no coordination cluster. The quickstart takes about five minutes.
Competitor information as of July 2026. Names and trademarks belong to their owners. Spot an error? Open an issue.
Competitor details verified against vendor docs as of July 2026 — corrections welcome via GitHub issue.