Jason Lee

Posted on Aug 13

Pinecone Wants $50 a Month Before You Store a Single Vector. pgvector Wants Nothing You Weren't Already Paying For.

#database #postgres #ai #rag

If you started a RAG project or an AI-agent-with-memory project any time in the last two years, you probably reached for a dedicated vector database without asking whether you needed one. That default is now genuinely up for debate, and it's worth re-running the decision with 2026 numbers instead of 2023 folklore.

Two things changed the math. First, Pinecone — long the default "just works" choice — moved its paid serverless tier to a $50/month minimum, on top of usage-based storage and read/write unit pricing. Second, pgvector, the Postgres extension that used to top out somewhere south of a million vectors before query latency fell apart, now runs comfortably into the tens of millions on ordinary Postgres — including the managed flavors most teams already pay for, like Supabase and Neon.

That's not a marginal shift. It means a meaningful slice of "RAG side project" and "internal tool with semantic search" use cases that used to justify a dedicated vector database no longer clearly do. Meanwhile Qdrant and Weaviate haven't stood still either — both keep shipping performance and hybrid-search improvements aimed squarely at the workloads that do outgrow Postgres. This piece compares all four on what they actually are, what they cost in practice (not on the pricing calculator), and where the real crossover point sits.

Why this comparison matters right now

Three years ago, "add a vector database" was a reasonable first move for almost any team building a RAG feature, because Postgres genuinely couldn't do approximate nearest-neighbor search at usable speed. pgvector existed but shipped only IVFFlat indexing, which meant slow builds, painful accuracy tuning, and query latency that fell off a cliff well before a million rows. Standing up Pinecone, or self-hosting Qdrant or Weaviate, wasn't over-engineering — it was close to the only option that worked.

That constraint quietly dissolved. pgvector shipped HNSW indexing, then quantization support, then iterative index scanning to fix filtered-query correctness — each release closing a gap that used to be a hard argument for a dedicated engine. At the same time, the workloads asking this question multiplied: 2026's wave of AI agents with persistent memory, retrieval-augmented coding assistants, and internal semantic-search tools means far more teams are making this decision than were making it in 2023, often with far less tolerance for adding a new stateful service to their stack. And the cost side moved too — Pinecone's serverless tier, which launched in 2024 specifically to fix the "I'm paying for idle pods" complaint about the old pod-based pricing, has itself picked up a pricing floor that changes who it's economical for. Put together, a decision that used to have one obvious default answer now genuinely depends on your numbers.

What each of these actually is

Pinecone is a fully managed, proprietary vector database. There is no self-hosted version and no open-source core — you use Pinecone's cloud or you don't use Pinecone. Its current architecture is "serverless," introduced in 2024, which separates storage from compute and bills by usage rather than by pre-provisioned pods. The pitch is zero operational overhead: no index tuning, no cluster sizing, no capacity planning.

Qdrant is an open-source vector database written in Rust, licensed Apache 2.0, distributed both as a self-hosted binary/container and as Qdrant Cloud, a managed offering. It's built specifically around approximate nearest-neighbor search at high throughput, with HNSW indexing, payload filtering, and quantization (scalar, product, and binary) as first-class features rather than bolt-ons.

Weaviate is also open source, self-hostable, and available as a managed cloud service. Its differentiator is hybrid search out of the box — combining dense vector similarity with BM25 lexical scoring and structured metadata filters in a single query — plus a modular system of built-in "vectorizer" integrations that can generate embeddings for you at ingestion time instead of requiring you to run your own embedding pipeline.

pgvector is not a database at all — it's a C extension that adds a vector column type and similarity operators to PostgreSQL. There is no separate service to run, no separate query language, and no separate consistency model: vectors live in the same tables, transactions, and backups as the rest of your relational data, and you query them with plain SQL, including joins against non-vector columns.

How they're actually built, and why it matters

The architectural split here isn't cosmetic — it determines what breaks and what you're trading away.

Pinecone's disaggregated storage-compute model is what lets it bill by actual usage instead of a standing cluster, and it's genuinely good at absorbing bursty or spiky workloads without you provisioning for peak. The cost of that is that every read and write goes through Pinecone's metering, which is where the pricing surprises tend to live (more on that below).

Qdrant and Weaviate are both "real" databases in the sense that you can run them yourself, inspect their source, and reason about their internals. Qdrant leans hard into raw ANN search performance — independent benchmarks summarized across recent comparisons put it roughly 10–25% faster than Weaviate or Milvus on comparable workloads, with p99 latency at 10 million vectors landing around 12ms versus roughly 16ms for Weaviate and 18ms for Milvus in the same test conditions. Weaviate trades some of that raw speed for richer schema semantics and native hybrid retrieval, which matters a lot if your queries mix "semantically similar to X" with "and published after date Y and category is Z."

pgvector's architecture is the real story of 2026, though. It ships two index types: IVFFlat, which partitions vectors into clusters and is fast to build but needs data present before indexing and loses accuracy under high-cardinality partitioning, and HNSW, a multilayer graph index that gives better speed-recall tradeoffs, doesn't require a training phase, and can be built on an empty table. HNSW performs "significantly faster" when the graph fits in maintenance_work_mem, per the project's own documentation — which is the crux of pgvector's scaling story: it's fast right up until your index no longer fits comfortably in memory, and then it degrades in a way that's very legible (you can watch maintenance_work_mem warnings and query latency climb together) rather than falling off a cliff.

There's a second, less obvious consequence of pgvector's design: because it's a regular Postgres index type, it inherits Postgres's whole operational toolchain for free. Streaming replication, point-in-time recovery, pg_dump, connection pooling with PgBouncer, row-level security — none of that had to be reinvented for vectors. A dedicated vector database has to build its own version of most of that list from scratch, which is real engineering effort that shows up as either missing features, added cost, or both. It's also why pgvector inherits Postgres's limits: a single-primary write bottleneck, and horizontal scaling that means read replicas or manual sharding rather than the built-in cluster rebalancing Qdrant and Weaviate offer natively.

Rust versus Go is also not a footnote for Qdrant and Weaviate. Qdrant's choice of Rust removes an entire class of garbage-collection pause and memory-safety bugs that can show up under sustained high-throughput indexing, which is part of why it benchmarks so consistently well on p99 tail latency rather than just average latency — GC pauses are exactly the kind of thing that shows up as tail latency spikes, not average slowdowns. Weaviate's Go runtime is a well-understood, easier-to-operate tradeoff, with a larger hiring pool and simpler debugging story, at the cost of occasional GC-driven latency variance under load.

What actually changed since "everyone said use Pinecone"

Three concrete things moved:

pgvector's practical ceiling moved up by roughly an order of magnitude. Where the old conventional wisdom capped realistic pgvector use at a few hundred thousand to a low-single-digit-million vectors, current guidance from Postgres-focused engineering write-ups puts production-viable RAG workloads at up to 50–100 million vectors before HNSW index rebuild time becomes the binding constraint. A more conservative, latency-focused read of the same landscape puts the comfortable ceiling lower — around 10 million vectors before a 10M-row HNSW index starts pushing past 8GB of RAM and query latency climbs past 250ms — with the honest practical range for most teams landing in "the low tens of millions" before a dedicated engine starts winning on latency and cost. Either way, that's a ceiling that covers a large share of real internal-tools and small-to-mid RAG deployments that used to reflexively reach for a separate vector database.
Pinecone's serverless pricing picked up a floor. The Standard tier now carries a $50/month minimum regardless of actual usage, alongside per-GB storage (~$0.33/GB), per-million-write-unit (~$4.50/M), and per-million-read-unit (~$18/M) charges. For a prototype, a staging environment, or a low-traffic internal tool, that floor is now larger than the entire infrastructure bill would be on Postgres you're already paying for. Pinecone has partly offset this with a one-time $250 bulk-import credit for Standard and Enterprise orgs, valid through August 30, 2026 — useful if you're migrating a large existing corpus in, less relevant if your workload is just small.
Production Pinecone bills have a track record of exceeding the calculator. Multiple independent cost analyses converge on the same pattern: real production bills commonly run 3–5x above what the pricing calculator estimates, driven by write-unit saturation and capacity fees that activate under sustained concurrent-agent load — exactly the access pattern a lot of 2026 AI-agent workloads produce, since agents tend to re-embed and re-query far more aggressively than a traditional search UI.

None of this makes Pinecone a bad product. It makes the "just default to Pinecone" heuristic worse than it used to be, specifically for workloads that are small, bursty in a write-heavy way, or cost-sensitive.

Why developers should actually care

Cost. pgvector's marginal cost for vector search is close to zero if you're already running Postgres for your application data — you're paying for CPU and RAM you'd need anyway. Pinecone's cost is transparent in structure but has proven unpredictable in practice, per the 3–5x-over-estimate pattern above. Qdrant and Weaviate sit in between: self-hosted, their cost is your infrastructure bill and your ops time; managed, both offer usage-based cloud tiers that are generally more predictable than Pinecone's read/write-unit model because you're paying more directly for compute and storage rather than per-operation metering.

Latency. If you need single-digit-millisecond p99 at high concurrency and tens of millions of vectors, Qdrant's benchmark position is the strongest of the four discussed here. pgvector is competitive up to its practical ceiling and then degrades predictably rather than catastrophically. Weaviate and Pinecone are both "fast enough" for the large majority of RAG use cases without being the latency leader.

Developer experience. This is pgvector's strongest card and it's underrated: your embeddings live next to your documents, your users, and your permissions in one database, queried with SQL you already know, inside transactions that already work. A dedicated vector database means a second system to keep in sync, a second thing to back up, and a second failure domain — your app can be "half up" if Postgres is healthy but the vector service isn't, or vice versa.

Lock-in. Pinecone is the only one of the four with no exit path other than re-embedding your data elsewhere — there's no self-hosted Pinecone. Qdrant and Weaviate are both genuinely open source (Apache 2.0 for Qdrant; Weaviate is also open source with a managed option), so "managed cloud" is a convenience choice, not a one-way door. pgvector has effectively zero lock-in since it's Postgres plus an extension available everywhere Postgres runs.

Security and maintainability. Fewer moving parts is a real security property, not just an ops convenience — one database means one auth model, one set of access controls, one thing to patch. Dedicated vector databases add a service that needs its own network policy, its own credential rotation, and its own on-call runbook. That's a fair trade when the workload genuinely needs it; it's dead weight when it doesn't.

This matters more than it sounds once you look at how access control actually gets enforced. With pgvector, if your application already uses Postgres row-level security to scope what a given user or tenant can see, that same policy automatically applies to vector search results — a query can't leak a document a user isn't authorized to read, because the authorization check and the similarity search run in the same engine against the same rows. With a separate vector database, you either have to replicate your permission model into that system's filtering layer and keep the two in sync as permissions change, or you fetch broader candidate results and filter them in application code after the fact — which is both slower and a place bugs hide. Multi-tenant SaaS products in particular should weigh this carefully: a permissions bug in a bolted-on filter layer is a data breach, not a UX bug.

Compliance and data residency work similarly. Self-hosted Qdrant or Weaviate, and pgvector by definition, keep vector data inside infrastructure you already control and have already satisfied whatever residency or audit requirements apply to. Pinecone and any managed Qdrant/Weaviate Cloud deployment mean vector data — which, remember, is a lossy-but-real encoding of your source documents, often reversible enough to leak sensitive content — now lives with a third party, subject to that party's region options, breach-notification terms, and subprocessor list.

Practical use cases per option

Pick Pinecone when you want zero infrastructure ownership and are willing to pay a premium for it — a small team shipping a customer-facing RAG feature fast, without anyone on the team who wants to own database operations, and where the workload is read-heavy and steady rather than write-bursty. It's also a defensible choice for a team that expects unpredictable, spiky growth and wants scaling to be someone else's problem contractually, not just technically.

Concretely: a five-person startup building a document Q&A product for enterprise customers, where the founding team is two backend engineers already stretched across billing, auth, and the core product — the operational cost of running any database themselves, dedicated or not, is the thing they're actually trying to avoid.

Pick Qdrant when your bottleneck is genuinely search performance at scale: high query-per-second requirements, tens of millions of vectors and up, and a team that's comfortable running (or paying Qdrant Cloud to run) a dedicated service. Its quantization options are also a real cost lever at large scale, shrinking memory footprint substantially with a controlled recall tradeoff — binary quantization in particular can cut memory footprint dramatically for embedding models that tolerate it well, which matters once you're paying for RAM across a multi-node cluster.

Concretely: a code-search product indexing every file across every repository a customer connects, where query volume is high, latency budgets are tight because it's in an IDE's autocomplete path, and the team already runs several other stateful services so one more isn't a step-change in operational burden.

Pick Weaviate when your retrieval problem is inherently hybrid — you need dense similarity combined with lexical/keyword matching and rich metadata filters in one query — and you'd rather use its built-in vectorizer modules than stand up your own embedding pipeline. This shows up constantly in e-commerce and support-ticket search, where "similar in meaning" alone produces bad results without also weighting exact SKU matches, brand names, or ticket status.

Concretely: a marketplace search feature where a query for "waterproof jacket size L under $100" needs semantic understanding of "waterproof jacket" fused with hard filters on size and price — the kind of query that's awkward to express as a single vector similarity search but is exactly what Weaviate's hybrid query API is built for.

Pick pgvector when you already run Postgres for your application, your vector count is realistically under the tens-of-millions range for the foreseeable future, and you'd rather have one database with joins and transactions than three moving parts.

Concretely: an internal knowledge-base search tool for a mid-size company, where the real requirement isn't "search a billion vectors fast," it's "search 200,000 documents while respecting the same row-level permissions the rest of the app already enforces in Postgres." Getting that permission join for free, inside a transaction, without querying two systems and reconciling the results, is worth more to that team than any latency benchmark.

What each vendor's marketing tends to leave out

Pinecone doesn't lead with the $50 floor or the 3–5x-over-estimate pattern; the pricing page emphasizes "pay only for what you use," which is true in structure but has not matched real bills for a meaningful share of production users, per the cost analyses cited above. There's also no answer to "what if I want to leave" beyond exporting and re-embedding elsewhere.

Qdrant markets its open-source core hard, but Qdrant Cloud is still a commercial managed product with its own pricing, and self-hosting at scale means you own sharding, cluster resizing, and the memory planning that HNSW at high vector counts demands — the "run it yourself" option isn't free, it's a different cost (engineering time) instead of a different bill.

Weaviate's modular vectorizer system is convenient, but each module you enable is effectively a dependency on an external embedding provider's API — you inherit that provider's rate limits, pricing, and outages as part of your search path unless you deliberately choose to bring your own embeddings.

pgvector's documentation is honest about its own limits — the project itself documents the 16,000-dimension cap on the standard vector type (2,000 for indexes, 4,000 for half-precision, 64,000 for binary vectors), and the 32TB default cap on non-partitioned tables — but "pgvector is production-ready" claims circulating in 2026 content often skip the HNSW rebuild-time wall and the fact that filtered approximate search can require iterative scanning workarounds to return correct result counts, which is a real query-planning subtlety, not a checkbox feature.

Comparison table

Dimension	Pinecone	Qdrant	Weaviate	pgvector
License / hosting	Proprietary, managed-only	Apache 2.0, self-host or managed	Open source, self-host or managed	Open source (Postgres extension)
Written in	Not disclosed (managed service)	Rust	Go	C
Index types	Proprietary	HNSW + quantization (scalar/product/binary)	HNSW	HNSW, IVFFlat
Hybrid (vector + lexical) search	Limited	Supported	Native, first-class	Requires combining with Postgres full-text search manually
Practical scale ceiling (single node/instance)	Effectively unlimited (managed scaling)	Tens to hundreds of millions	Tens to hundreds of millions	Roughly 10M–50M+ vectors depending on latency tolerance
Pricing model	$50/mo min (Standard) + $0.33/GB storage + $4.50/M write units + $18/M read units	Free self-hosted; usage-based cloud tiers	Free self-hosted; usage-based cloud tiers	Free — cost of your existing Postgres
Vendor lock-in	High (no self-host path)	Low (open source, portable)	Low (open source, portable)	None (standard Postgres extension)
Transactions / joins with app data	No	No	No	Yes, native SQL
Reported latency leader in cross-vendor benchmarks	No	Yes (~10–25% faster than Weaviate/Milvus in cited comparisons)	No	Competitive up to ceiling, then degrades
Operational surface	None (fully managed)	One extra service to run/monitor	One extra service to run/monitor	Zero extra service — same Postgres instance

An independent read

The honest takeaway is that "which vector database" has quietly become the wrong first question for a large share of projects. The right first question is "how many vectors, at what latency, with how much budget for a second system" — and for a lot of 2026 RAG projects, the answer to that question routes straight to pgvector, not because it's the most powerful option on this list, but because it's the one that costs nothing incremental and removes an entire failure domain. That's a genuinely different recommendation than the industry consensus of two years ago, and it's driven by pgvector's own maturation more than by any competitor getting worse.

That said, "pgvector is now good enough for most people" is not the same claim as "dedicated vector databases are obsolete." Qdrant's benchmark lead is real and matters if you're serving search at meaningful concurrency; Weaviate's hybrid-search-as-a-primitive is a genuine time-saver if your retrieval logic actually needs it; and Pinecone's zero-ops model is worth its premium for teams that would rather buy their way out of database operations entirely, provided they go in with eyes open about the $50 floor and the historical gap between estimated and actual bills.

Who should pick what

Solo devs and small teams building an MVP or internal tool, already on Postgres (Supabase, Neon, RDS, or self-managed), under ~10 million vectors: pgvector. You get vector search for free and one less system to operate.
Teams with an existing, latency-sensitive, high-QPS search product scaling past tens of millions of vectors, with engineering capacity to own infrastructure (or budget for Qdrant Cloud): Qdrant.
Teams whose retrieval logic is fundamentally hybrid — keyword plus semantic plus metadata filters — who want that as a built-in primitive rather than something they hand-roll: Weaviate.
Teams that want to buy their way out of vector infrastructure entirely, have budget for the premium, and have workloads that are steady rather than write-bursty: Pinecone — with a firm eye on the $50 floor and a habit of monitoring actual write-unit consumption against the calculator estimate from week one.

Discussion: if you've already migrated a production workload off a dedicated vector database and onto pgvector (or the reverse — off pgvector onto a dedicated engine), what was the actual trigger — was it a hard technical wall like index rebuild time, or was it a cost or ops decision made well before you hit any technical ceiling?

Sources:

DEV Community