pgvector vs Pinecone vs Weaviate: Do You Need a Vector Database at All?

If you're already running Postgres and you're under a few million vectors, the honest answer is probably no, you don't need a separate vector database. pgvector, the open-source extension that turns Postgres into a vector store, handles that range on hardware you can price in five minutes. Pinecone and Weaviate start earning their cost once you're past it: once vector count, query concurrency, or how long an index rebuild takes starts fighting your transactional workload for memory and CPU on the same box.

This piece prices all three the way you'll actually pay for them, not at headline rates: one workload at startup scale, the same shape of workload at production scale, across pgvector on four managed Postgres hosts (Supabase, Neon, AWS RDS, Google Cloud SQL) and against Pinecone's and Weaviate's own published rate cards. The ranking changes between the two scenarios, and that flip is the most useful thing here.

TL;DR

What Each One Actually Is

pgvector isn't a company and it doesn't have a price list, because it isn't a product. It's a PostgreSQL extension (CREATE EXTENSION vector;) that adds a vector column type and two index types, HNSW and IVFFlat, to a database you're already running. There's no separate bill for pgvector itself. Every dollar you spend on it is a dollar you spend on Postgres compute, memory, and storage, through whichever host runs your database. That's the detail most comparison pages skip, and it's the one that matters most for this decision: the question was never "what does pgvector cost," it's "what does a Postgres big enough to hold your vectors well cost."

Pinecone is the opposite end of the spectrum: a fully managed, closed-source vector database with no self-hosted version at all. You don't install it, you don't patch it, and you can't run it on your own hardware even if you wanted to. You get an API, you pay for storage and for read/write operations, and Pinecone runs the infrastructure. That trade buys you zero operational burden and real elasticity under spiky query load, at the cost of being permanently on their pricing curve.

Weaviate sits in between. The core is BSD-3-Clause, genuinely open source, so you can self-host it for free on your own infrastructure, or pay for Weaviate Cloud (their managed offering) and skip the ops work. It also supports hybrid search (keyword plus vector, in one query) natively, which pgvector and Pinecone both require you to assemble yourself from separate pieces, usually Postgres full-text search plus pgvector for the Postgres path, or a second service alongside Pinecone.

If what you're storing in any of these is the output of an embedding model, our explanation of what embeddings actually are covers how text and images become the vectors you're indexing here. And if the reason you're evaluating a vector store is to ground an AI agent or assistant in your own data, see RAG for AI agents and the RAG Assistant pattern for the retrieval side of this decision, and AI agent memory if the use case is a persistent, searchable memory store rather than a one-shot retrieval index.

Licensing, Verified

Vendor pivots and relicensing are common enough in this space in 2026 that the license itself is worth checking before you build on any of these, not just the feature list.

Two things worth flagging plainly. First, pgvectorscale, the extension Timescale built on top of pgvector to add a DiskANN-style index and better compression, stayed fully open source (PostgreSQL License) rather than following the 2026 trend of projects moving to source-available terms. If you need it, you can use it without a commercial agreement. Second, Weaviate's core database, the part that does vector search, is genuinely open source; it's specific enterprise administration features that carry a commercial key requirement, not the search engine itself. Pinecone is the one name on this list with zero open-source or self-hosted path at any price. That's not a criticism, it's a fact to plan around if vendor lock-in is a board-level concern.

Where pgvector Stops Being the Right Answer

Here are the concrete thresholds, pulled from pgvector's own documentation, not adjectives.

That filtering behavior is worth sitting with. With an approximate index, pgvector scans the index first and applies your WHERE clause after, by default. If you're filtering to a specific tenant, date range, or document type and that filter is narrow, you can scan right past your matches before the filter ever gets applied, which quietly tanks recall. pgvector 0.7.0 and later ships iterative index scans (hnsw.iterative_scan = strict_order or relaxed_order) specifically to fix this by automatically scanning more of the graph when a filter is narrow, but it's opt-in, not automatic, and it's a real gotcha if you don't know to turn it on.

pgvector's Real Cost: Pricing the Postgres, Not the Extension

Here's what each of the four managed Postgres paths actually charges, fetched from each vendor's own pricing page.

The structural point to take from this table: three of the four hosts bill you a flat, predictable compute rate regardless of how many queries you run. Only Neon's pay-as-you-go compute model ties cost to actual CU-hours consumed, which is cheap for bursty or idle-heavy workloads and expensive for anything that needs to stay warm around the clock. That distinction matters more than it looks like it does once you get to the second pricing scenario below.

Pinecone's Own Pricing

Pinecone does publish the unit formulas, and they matter far more than the sticker price. Per its cost documentation, a query costs 1 RU for every 1 GB of namespace size with a 0.25 RU floor, and top_k makes no difference, while an upsert costs 1 WU per KB of the request with a 5 WU floor. The consequence is that your read bill tracks the size of the namespace each query targets rather than your query count alone, which makes namespace design a pricing decision as much as a modeling one. Run a real test at your own dimension count and namespace layout before committing to a tier.

Weaviate's Own Pricing

Pricing One Real Workload: Startup Scale

500,000 vectors, 1,536 dimensions (the size OpenAI's text-embedding-3-small produces), modest traffic of roughly 2 million queries a month. Raw vector data alone is about 2.9GB; with HNSW graph overhead, the comfortable working set is roughly 6-8GB of RAM to keep the index resident.

At this size, Pinecone and Weaviate are genuinely competitive with, or cheaper than, standing up Postgres compute sized for a comfortable HNSW graph, if you're paying for that Postgres instance from scratch. The caveat that matters: most readers asking this question already run Postgres for their application. The real comparison usually isn't "$0 versus $135," it's the marginal cost of upgrading an instance you already pay for by one or two compute tiers, which on Supabase is the difference between Medium and Large ($50/month), not the full $135. Price your actual marginal upgrade, not a fresh instance, before concluding pgvector is more expensive than it is.

Pricing the Same Workload at Production Scale

10 million vectors, same 1,536 dimensions, heavier traffic at roughly 100-130 million queries a month, with continuous ingestion. Raw vector data is about 61GB; with HNSW overhead, the comfortable working set climbs past 120GB of RAM.

That's the ranking flip, and at this scale it is not close. At startup scale, the serverless vector databases are competitive on pure infrastructure cost. At production scale, pgvector on a correctly sized AWS RDS or Google Cloud SQL instance is the cheapest way to hold 10 million vectors, while Neon's elastic pricing, the cheapest pgvector host at small scale, becomes the most expensive of the fixed-capacity paths once you need sustained large capacity instead of bursty compute. The metered options are in a different bracket altogether: Pinecone's and Weaviate's pricing keeps climbing with query volume in a way none of the fixed-capacity Postgres options do, and on a single-namespace layout Pinecone's read units alone can run more than an order of magnitude above the most expensive Postgres box on this table. A traffic spike costs more on Pinecone and nothing extra on a Postgres instance you have already paid for. That asymmetry, not the headline rate, is what you are really choosing between.

The other real cost at this scale isn't on any pricing page: rebuilding a 10-million-row HNSW index takes real wall-clock time, and your write throughput and query recall both take a hit during that rebuild unless you've planned around it (a replacement index built concurrently, or a maintenance window). Pinecone and Weaviate absorb that operational burden for you, as part of what their usage fees pay for.

Index Types and What They Actually Trade Off

Who Has to Run This

When pgvector Is the Right Call

If you already run Postgres for your application data, and your vector workload is under a few million rows, pgvector is the right default, not a compromise. You get transactional consistency between your vectors and the rest of your data (no syncing two systems, no eventual-consistency bugs), one fewer vendor to manage, and a cost that's usually already inside a Postgres bill you're paying anyway. If your team knows SQL, there's no new query language to learn. And because filtering, joins, and vector search all happen in the same query, you can combine a vector search with a real business-logic WHERE clause (tenant ID, permissions, status) in ways that are genuinely awkward to replicate against a separate vector API.

When Pinecone Is the Right Call

Pinecone earns its cost when you want zero infrastructure to manage, full stop, and your query volume doesn't push the per-unit metering past what a dedicated instance would cost. It's also the stronger pick when you expect genuinely spiky traffic (a launch, a seasonal pattern, an unpredictable product surface) and don't want to provision for peak capacity you'll mostly not use. And if your data genuinely lives outside any Postgres instance already, standing up Postgres just to get pgvector isn't a real savings, it's a new system to operate for no reason but the price of the extension. If cost is the worry, the Pinecone alternatives guide prices 12 other options.

When Weaviate Is the Right Call

Weaviate is the right call when hybrid search, keyword plus vector ranking in one query, is a real requirement rather than a nice-to-have, since it's native rather than bolted together from two systems. It's also the pick when an open-source, self-hostable requirement is non-negotiable for compliance or vendor-risk reasons but you still want the option to hand operations to a managed service later. And its multi-tenancy model (collections and tenants as first-class concepts) is a genuine advantage if you're building a product that serves many customers' data in isolation from a shared index. The Weaviate alternatives guide covers what you'd lose by moving off it.

Keep It in Postgres, and Revisit at This Scale

This isn't a hedge, it's the actual recommendation for most readers: if you're under roughly 2-5 million vectors, your queries aren't fighting your transactional workload for resources, and your metadata filters aren't so selective that post-filter recall is visibly hurting you, stay in Postgres. Add pgvector, size your instance using the thresholds table above, and revisit this decision at one of three concrete signals: your HNSW graph no longer fits comfortably in maintenance_work_mem on a reasonably priced instance, your index rebuild time has grown past what your deployment process can tolerate, or pg_stat_statements shows vector queries consistently starving the rest of your database. Those are measurable, not vibes, and they're the honest trigger for a migration, not an arbitrary vector count someone put in a blog post. When one of those signals trips, the vector database roundup prices 12 vector databases at a 1-million-vector workload.

If your evaluation is part of a broader AI knowledge or retrieval buying decision rather than just picking an index, our guide to choosing AI knowledge base software covers the layer above this one: grounding, permission-aware search, and how AI pricing meters more broadly. And if the total cost of the surrounding AI system, not just the vector store, is what you're trying to model, see AI total cost of ownership for the other hidden line items that tend to surprise teams after the pilot. For retrieval architectures that lean more on explicit relationships than nearest-neighbor similarity, knowledge graphs are worth understanding as the alternative, or complement, to a pure vector approach.

Decision Framework

What to Do Next

Don't buy a vector database before you've measured whether you need one. If you're already running Postgres, the lowest-risk next step is CREATE EXTENSION vector, load a representative sample of your real data, build an HNSW index, and run EXPLAIN ANALYZE against your actual query patterns, including your real metadata filters. That tells you, in an afternoon, whether you're comfortably inside pgvector's range or close to one of the thresholds above. Only shop Pinecone or Weaviate once you have a concrete, measured reason to, because then you'll know exactly which tradeoff you're buying and at what workload size, instead of reacting to whichever one ranked first in a search result. When you do, Pinecone vs Weaviate goes deeper on compliance and vendor risk, and Pinecone vs Weaviate vs Qdrant adds Qdrant as a fully open-source third option.