Comparison
polign_db is an object-storage-native vector and hybrid search database. This page explains how it compares to Pinecone, turbopuffer, Amazon S3 Vectors, LanceDB, Qdrant, Milvus, and Weaviate.
For small scale operations, Postgres with pgvector is usually the right answer. polign_db earns its keep in handling larger and scaled workloads, or when the corpus is mostly cold and you want to stop renting RAM for it.
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, and Pinecone's serverless tier moved to the same storage–compute separation; 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, and it runs in your own account, 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 | Pinecone | S3 Vectors | LanceDB | Qdrant | Milvus | Weaviate | |
|---|---|---|---|---|---|---|---|---|
| What you own | ||||||||
| Open source | No closed source; self-hosted binary | No closed source | No managed service | No managed service | Yes | Yes | Yes | Yes |
| Your data on your bucket, in your VPC | Yes — any S3-compatible store | Partial vendor-run; BYOC tiers vary | Partial vendor-run; BYOC at enterprise tiers | 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 | Partial in your VPC, but node disk and RAM hold the data |
| Runs in your own account without a paid tier gate | Yes — the self-hosted binary is the product; there is no tier that unlocks it | No BYOC and single-tenancy are Enterprise: ≥$4,096/mo plus a 35% usage premium | No BYOC is an enterprise-tier preview | No the bucket is AWS's to manage | Partial the OSS library runs anywhere; fully decoupled compute is the Enterprise product | Yes — OSS self-hosted | Yes — OSS self-hosted; Zilliz BYOC is a separate paid product | Yes — OSS self-hosted |
| What you operate | ||||||||
| Infrastructure | Minimal one binary + a bucket | None SaaS | None SaaS | None managed | None embedded | Some binaries + Raft cluster at scale | Heavy Kubernetes + etcd + MQ + object store | Some Go binary, but a Raft cluster and its own schema service |
| Recovery | Yes the bucket is the source of truth; a replacement warms on demand | Yes | Yes managed | Yes managed | Depends your files, your backups | Recovers replicas re-sync and rebalance | Recovers re-replication across the cluster | Recovers replica re-sync from surviving nodes |
| Cost | ||||||||
| Hold 1 TB for ~$20 / month | Yes — cold-first mode | Close vector storage + usage pricing | No managed storage rates (~$330/TB list) + usage | Close vector storage + per-request pricing | Yes — on your S3 | No replicated RAM/SSD (~$600–3,000) | No replicated disk tiers | No node disk and RAM; object storage is an offload tier, not the serving path |
| Idle data costs | Yes idle collections pay only storage pricing; queries pay per-download | Yes | Yes serverless: idle pays storage only | Yes | Partial disk you provision | No nodes run either way | No nodes run either way | Partial inactive tenants can be offloaded to object storage; nodes still run |
| Large corpus | Yes — GET-cost-bound, not RAM-bound | Yes | Yes storage–compute separated | Yes | Partial disk-bound | No RAM/disk-bound | Partial tiered storage, ops-heavy | Partial RAM-bound hot set, offload for the rest |
| What a write means | ||||||||
| Read-your-writes by default | Yes — durable-on-ack, per-collection total order, and the next query sees the write, hot or cold. One documented freshness exception: BM25 text becomes keyword-searchable at the next segment flush | Yes — strong read-your-writes, with a ~10 ms floor | No eventually consistent — freshness lag (typically seconds), trackable via LSN headers; not guaranteed per query | Partial strongly consistent per index, but freshness is not contractually specified | Partial managed within a single process | No availability-first by default; concurrent updates to one point can leave it inconsistent. Tunable up | No defaults to bounded staleness. Tunable up to session/strong | Partial tunable consistency levels on the replication path |
| Write ceiling per unit of isolation | ~6,200/s per log, measured; collections are independent, so throughput scales across them | 1 WAL entry/sec documented per namespace — batch or fan out for high-write agent fleets | Metered write units, not a documented rate ceiling | 1,000/s per index, and metadata is capped at 40 KB with only 2 KB filterable across 50 keys | Depends in-process; one writer per table | High bounded by the nodes you provision | High the MQ absorbs it; that MQ is yours to run | High bounded by the nodes you provision |
| What your users get | ||||||||
| Hybrid BM25 + vector search | Yes — server-side RRF & linear fusion | Yes | Partial sparse–dense vectors; you weight and merge the legs | No dense only | Partial in-process, bring a reranker | Partial bring your own sparse vectors | Yes — built-in BM25 | Yes — native BM25 + vector in one API call |
| Rich metadata filtering | Yes exact match, lists, ranges, and exists, combined with and/or/not, over typed values (string, number, boolean) compared by type. Filters run during the search, hot or cold, and stay accurate even when they match few records | Yes exact filters | Yes operator filters | Basic | Yes SQL predicates | Yes best-in-class filtered HNSW | Yes full expressions | Yes GraphQL/gRPC where filters |
| 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 | Warm cached serverless reads; pod tiers for the low tail | No relaxed-latency tier | Yes in-process | Yes built for it | Yes plus GPU indexes | Yes RAM-resident hot set |
| 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 | Yes — namespaces within an index | Partial index-per-tenant, request-priced | Partial table-per-tenant, embedded | Partial payload partitioning in shared collections | Partial partitions; 100k collections | Yes — native multi-tenancy, its strongest feature here; inactive tenants offload to object storage |
// supported partial / depends not available · competitor cells summarize vendor documentation; we link primary sources rather than restate their marketing.
Every qualifier here is doing work, because each one on its own is already taken. polign_db is the option in this table that is object-storage-native on the serving path (not as a cold offload tier), ships BM25 hybrid in the same binary, runs on a bucket you own with no tier that unlocks it, and gives you read-your-writes by default. The systems that match any one of those give up at least one of the others.
The freshness envelopes, side by side
Read-your-writes is the claim we lean on hardest, so here is its shape in full rather than as a footnote. The two legs of a hybrid query do not become fresh at the same moment:
| Query leg | When a just-acknowledged write is visible | Why |
|---|---|---|
| Vector search | Immediately, on the next query, hot or cold | Each node follows the log tail into an in-memory overlay that is authoritative for any id it knows, and merges it over segment results |
| Metadata filters, point reads, listings | Immediately | Same overlay (listing a cold resource the node keeps no index for returns 501 by design — its records live in segments) |
| BM25 keyword search | At the next segment flush, seconds later | The lexical index is built by the persistor when segments are written; the overlay covers vector reads, not text |
If an agent writes a memory and immediately searches for it by embedding, it finds it. If it immediately searches for it by keyword, it may not until the flush lands. That asymmetry is deliberate and it is the contract's one freshness exception — the mechanism is documented here.
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 and 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. 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 corpus is under roughly 50 million vectors and you already run Postgres. This is the honest default, and it is not close: your vectors sit next to the rows they belong to, in one transaction, with backups and access control you already operate. pgvectorscale has been measured at 28× lower p95 latency than a managed serverless index at 99% recall. Reach for a dedicated engine when the corpus outgrows the box, when the working set is mostly cold and you resent paying RAM prices for it, or when you need thousands of independently-hot collections.
You want native multi-tenancy and hybrid BM25 + vector in a single API call from a mature, well-documented engine, and your hot data legitimately fits node disk and RAM. Its object-storage support is an offload tier for inactive tenants rather than the serving path, so the economics change the moment most of your corpus is cold. It is also the better answer if you need per-tenant isolation inside one cluster, which polign_db does not model.
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 vendor holding your search path. It's the strongest endorsement of the model there is; it just isn't yours to run.
You want the most mature managed retrieval platform: hosted embedding and reranking, enterprise compliance, a large ecosystem. A vendor-run serverless index is acceptable. The trade is that your data lives in Pinecone's account (BYOC is an enterprise-tier preview), the pricing is managed-service pricing, and consistency is eventual: writes become visible within seconds, but reading what you just wrote isn't guaranteed on any given query, which matters when an agent must read its own last step.
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, so 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.
Pricing, side by side
The families also differ in what the meter counts. Managed services meter storage, reads, and writes at their own rates; provisioned engines bill for the nodes whether you query them or not; polign_db has no meter of its own. The bill is your cloud provider's list prices for a VM, a bucket, and the requests your traffic makes. List prices as published in August 2026:
| polign_db | turbopuffer | Pinecone | S3 Vectors | LanceDB | Qdrant | Milvus | Weaviate | |
|---|---|---|---|---|---|---|---|---|
| Pricing model | Self-hosted — your cloud provider's list prices, no markup or metered units on top | Usage-based SaaS | Usage-based serverless (Standard plan shown) | Usage-based, AWS-billed | Free OSS embedded; LanceDB Cloud is usage-based | Free OSS; Qdrant Cloud bills provisioned nodes hourly | Free OSS; Zilliz Cloud bills compute-units + storage | Free OSS; Weaviate Cloud is usage-based on stored vector dimensions |
| Storage | Your bucket's rate — $0.023/GB·mo on S3 Standard | Up to $0.33/GB·mo list, volume-discounted | $0.33/GB·mo | $0.06/GB·mo | Your disk or bucket's rate | Provisioned RAM/disk — capacity rented, not per-GB metered | Zilliz: $0.04/GB·mo, plus compute | Metered per million stored vector dimensions and tiered by SLA, not per GB |
| Queries | S3 GETs at $0.40 per million. A search checking 8 regions makes 8 GETs, so ~$3.20 per million searches | $1/PB queried, 1.28 GB minimum billed per query | $16 per million read units | Per-request fee + tiered $/TB scanned by index size | None — in-process compute | None metered because the nodes bill either way | Zilliz: $0.096 per CU-hour while querying | Not metered separately — folded into the dimension-based rate |
| Writes | S3 PUTs at $5.00 per million, shared across batched writes — ~$0.01 per million writes measured | Up to $2.00/GB written, batch discounts to 50% | $4 per million write units | $0.20/GB uploaded | None — in-process | None metered | Zilliz: CU-hours while indexing | Not metered separately |
| Monthly minimum | The VM you run. Every number on the benchmarks page comes from a single 8-vCPU instance | $16 Launch / $256 Scale; enterprise ≥$4,096 with a 35% usage premium | $0 Starter tier; $50 Standard, $500 Enterprise | None | None (OSS) | Free 1 GB cluster; paid nodes from first hour | Zilliz free tier; none self-hosted | Free sandbox; Serverless Cloud carries a monthly minimum. None self-hosted |
// vendor list prices as of August 2026. Regional variants, volume discounts, and repricing will move these; check the pricing links under Sources before you budget.
Pinecone's $50 floor and turbopuffer's $16 floor are small, and both bill idle data at storage rates similar to polign. At corpus scale with query volume, polign comes out about 14× cheaper while dealing with metered storage rates and additional query costs.
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 August 2026. Names and trademarks belong to their owners.
Competitor details verified against vendor docs as of August 2026. Corrections welcome at connect-us@polign.com. Pricing: Pinecone · turbopuffer · S3 / S3 Vectors · Qdrant Cloud · Zilliz Cloud (Milvus) · LanceDB Cloud · Weaviate Cloud.