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.
Compare the deployment you would actually run: where durable data lives, what serves queries, and who operates it. A product can support more than one model.
Architectural differences
These deployment patterns overlap. Embedding a database in your application describes where its code runs; it does not require the data to live on local disk. LanceDB, for example, supports both embedded execution and direct object-storage access.
Serving uses indexes in RAM or on SSD. Durability, replication, and object-storage support depend on the engine and deployment.
The database runs inside your application. LanceDB OSS can read local files or object storage; the application owns its compute and maintenance lifecycle.
Durable data and index artifacts live in object storage. Serving compute can be replaced independently of that storage.
LanceDB OSS can connect directly to S3, GCS, and Azure Blob. Its S3 storage path supports concurrent writers without an external commit coordinator. LanceDB Enterprise adds distributed query execution and background indexing over durable object storage. Polign packages HTTP and gRPC serving, hybrid search, and object-storage persistence in one self-hosted binary. Bucket ownership and storage–compute separation are shared capabilities.
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.
The LanceDB column distinguishes the OSS library from the commercial Enterprise service. LanceDB details were reviewed on September 8, 2026; other competitor entries retain their August 2026 review date. Linked documentation describes capabilities; this matrix is not a head-to-head performance benchmark.
| 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 | OSS open-source library; Enterprise is commercial | 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 OSS: your bucket. Enterprise: BYOC and bring-your-own-bucket deployments | 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 | OSS runs in your account with direct bucket access; the Enterprise service is commercial | 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 | Depends OSS runs in your app; Enterprise operates a cluster with separate query and indexing workers | 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 | Object-backed replacement compute reopens durable tables from the bucket. Local-file deployments depend on local storage and 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 | OSS your bucket's storage rate; compute, requests, and index storage are additional | 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 | OSS on S3 data persists with application compute stopped; storage charges remain. Enterprise pricing depends on deployment | 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 | Yes object-storage datasets; Enterprise adds distributed serving and indexing | 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 | Configurable OSS cross-process refresh is off by default; read_consistency_interval=0 checks every read. Enterprise freshness is deployment-configured |
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 | Workload-dependent concurrent writers supported; storage, batching, and commit contention affect throughput | 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 | Yes BM25 full-text search + vectors, with built-in RRF fusion by default | 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 | Workload-dependent local or warm reads can be fast; cold object-storage reads add latency | 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 | Depends tables and hierarchical namespaces; access isolation depends on deployment | 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.
Polign brings a shared search service to a bucket you own.
One self-hosted binary provides HTTP and gRPC APIs, vector and BM25 hybrid search, and durable object-storage writes. LanceDB also supports object storage, hybrid search, and concurrent writers. Evaluate Polign when you want this service packaged for your own infrastructure; evaluate LanceDB for an embedded library or its broader Enterprise platform. Compare operating effort, recovery, freshness, and total cost on the deployment you intend to run.
Polign write visibility
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.
For LanceDB OSS, reads check for updates from other writers according to
read_consistency_interval: unset disables automatic refresh, zero checks on
every read, and a positive interval checks periodically. Enterprise sets freshness at
deployment level. Compare equivalent freshness settings when measuring latency; see
LanceDB's consistency documentation.
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.
You want a self-hosted HTTP/gRPC service for vector and hybrid search, backed by your own bucket and IAM policies. Mostly idle agent-memory collections and replaceable serving nodes are a useful workload to evaluate. Polign includes persistence and index maintenance in the server; validate startup, maintenance capacity, write contention, and query freshness with your data.
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. RAM-resident indexes win that race; you pay for the win in replicated-RAM/SSD economics and capacity coupled to compute.
You want an open-source library for retrieval and agent memory, with local or object-storage tables, hybrid search, and concurrent writers. LanceDB's table model also supports multimodal data, curation, and training workflows. Choose Enterprise when you want distributed serving, feature engineering, and managed or BYOC operations. A shared service and concurrent writes are supported deployment options.
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
Storage tiers have different costs and latency profiles. Provisioned RAM and SSD remain billable while idle; object storage charges for retained data and requests. The examples below illustrate storage costs, excluding serving compute, maintenance, request charges, and software or service fees.
| Storage tier | ~$ / TB · month | Who serves from it |
|---|---|---|
| Replicated RAM | $3,000+ | Deployments keeping their serving indexes in RAM |
| 3× replicated SSD | $600 | Deployments retaining three local-disk replicas |
| Object storage + SSD cache | $70 | polign_db warm path, turbopuffer, and LanceDB Enterprise |
| Object storage only | $20 | polign_db cold-first mode and LanceDB OSS on object storage |
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
Compare software or service fees alongside infrastructure costs. Self-hosted Polign has no software fee and no node limit; the paid option is an annual Production Agreement for support. LanceDB OSS has no software fee; Enterprise terms require a quote. Both self-hosted products incur compute, storage, and request costs. Other vendors' listed prices below retain their August 2026 review date.
| polign_db | turbopuffer | Pinecone | S3 Vectors | LanceDB | Qdrant | Milvus | Weaviate | |
|---|---|---|---|---|---|---|---|---|
| Pricing model | Self-hosted: your infrastructure costs. Software is $0 with no node limit; support agreements are optional | Usage-based SaaS | Usage-based serverless (Standard plan shown) | Usage-based, AWS-billed | OSS: no software fee, local or object storage. Enterprise: request a quote | 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 | OSS: your disk or bucket's rate, including indexes. Enterprise: deployment-specific terms | 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 | OSS: compute and storage-request costs; no LanceDB per-query fee. Enterprise: quoted terms | 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 | OSS: compute, storage writes, and index maintenance; no LanceDB per-write fee. Enterprise: quoted terms | None metered | Zilliz: CU-hours while indexing | Not metered separately |
| Monthly minimum | Infrastructure you run. $0 software fee, no node limit | $16 Launch / $256 Scale; enterprise ≥$4,096 with a 35% usage premium | $0 Starter tier; $50 Standard, $500 Enterprise | None | OSS: no software minimum; infrastructure still costs. Enterprise: request a quote | 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 |
// Polign and LanceDB pricing descriptions reviewed September 8, 2026; other vendor list prices retain their August 2026 review date. Check regional rates, discounts, and the pricing links under Sources before you budget.
Polign and LanceDB OSS can use the same object-storage rates. Any cost advantage depends on the workload: include index size, cache allocation, request counts, compaction, retained write logs, and operating effort. Compare total cost at equivalent retrieval quality, freshness, and latency targets.
Run it on your bucket this afternoon
One Go binary, one S3-compatible bucket, no coordination cluster. The quickstart takes about five minutes.
LanceDB information reviewed September 8, 2026. Other competitor entries retain their August 2026 review date. Names and trademarks belong to their owners.
LanceDB sources reviewed September 8, 2026: OSS connections · storage and concurrent S3 writers · concurrency and scale FAQ · consistency · full-text search · hybrid search · namespaces · Enterprise architecture · deployment models · August 7 bring-your-own-bucket announcement.
Other competitor entries retain their August 2026 review date. Corrections welcome at connect-us@polign.com. Pricing and commercial terms: Pinecone · turbopuffer · S3 / S3 Vectors · Qdrant Cloud · Zilliz Cloud (Milvus) · LanceDB Enterprise · Weaviate Cloud.