pgvector stores vectors at 4×dimensions+8 bytes before indexing; see how Pinecone and Weaviate compare on latency, recall, and ops. Read now.
What “4×dimensions+8” actually means for storage
Before you pick a product, understand the raw footprint of a single vector. With pgvector’s common float32 path, each embedding occupies four bytes per dimension plus a small fixed header of eight bytes before any index is built. A 1,536-dimension vector is therefore a few kilobytes of payload on its own; multiply that by millions of rows and the heap, indexes, and vacuum behavior start to dominate disk and RAM planning. That formula is a useful first estimate for capacity, not a full cost model—indexes, metadata columns, and write amplification all add more.
Pinecone and Weaviate abstract that storage math behind managed or self-hosted services. You still pay for dimension count and collection size, but you reason less about row headers and more about index type, replicas, and how filters interact with the vector store. The practical takeaway is the same across all three: dimension length is a first-class capacity and latency lever, so choose embedding models with both quality and byte cost in mind.
Latency, recall, and how the three approaches trade off
Approximate nearest-neighbor search is always a compromise between how fast you answer and how completely you find the true neighbors. Higher recall usually means more candidates probed, larger graphs or lists, or more compute per query. Lower latency often means coarser indexes, smaller working sets, or fewer hops in the search structure. None of Pinecone, Weaviate, or pgvector escapes that curve; they just expose different knobs and operational defaults.
pgvector keeps vectors next to relational data, which is excellent when you need joins, transactions, and SQL filters in the same request path—but your latency and recall then share the same machine with the rest of the database workload. Pinecone is built as a dedicated vector service: you push embeddings and query them without co-locating OLTP traffic, which simplifies performance isolation at the cost of another system boundary. Weaviate sits between pure SQL and pure API-only stores: it is vector-first with a query model and schema of its own, so you design objects and properties around retrieval rather than folding everything into tables.
- pgvector: best when vectors are an extension of an existing Postgres app and you accept shared resource planning.
- Pinecone: best when you want a managed vector layer with clear separation from the primary database.
- Weaviate: best when you want a dedicated vector database with object-level modeling and flexible deployment options.
Operations: who owns indexes, scaling, and failure modes
Ops is where product choice often matters more than raw search quality. With pgvector, you inherit Postgres backup, replication, connection pooling, and migration discipline—and you also inherit index build time, bloat, and the need to size CPU and memory for both SQL and ANN. Upserts, deletes, and concurrent writes need the same care you already give hot tables. Monitoring is familiar if you already run Postgres well; if you do not, vector indexes will surface that gap quickly.
Pinecone shifts index lifecycle, scaling, and availability into a service model: fewer low-level knobs, more attention to API usage, namespaces or collections, and how your app retries and batches. Weaviate, depending on how you run it, can look like either a managed product or infrastructure you operate—schema changes, module configuration, and cluster health become part of your runbooks. In all cases, plan for re-embedding when models change, for filter-heavy queries that stress hybrid search, and for cold-start or empty-result behavior when collections are small.
A practical way to choose
Start from data gravity. If embeddings must stay transactional with user or product rows and your team already runs Postgres, pgvector is the default path—size for 4×dimensions+8 per vector plus indexes, then validate recall and p95 latency on your real filters. If retrieval is a product feature of its own and you want isolation from the primary database, evaluate Pinecone or Weaviate on integration fit, deployment preference, and how cleanly your pipeline can batch inserts and measure recall against a held-out neighbor set. Pick the system that matches where vectors live, who will operate the indexes, and how you will re-measure quality when embeddings or query patterns change—not the one that merely lists the right buzzwords.