Decision comparison
pgvector vs Turbopuffer
pgvector and turbopuffer answer opposite ends of the same question. pgvector keeps embeddings in PostgreSQL beside the rows they describe, so updates are transactional, filtering is full SQL, and no new system exists. turbopuffer is a dedicated serverless service on object storage, priced so that large or mostly-idle corpora cost very little to hold.
Direct comparison. These are reviewed substitutes bought for the same job, so the differences below are the ones that decide between them.
All 2 are vector databases.
Quick Comparison
| Decision factor | pgvector | Turbopuffer |
|---|---|---|
| What it is | An extension that adds vector types and indexes to PostgreSQL, so embeddings live beside the application's existing tables | A serverless vector and full-text search engine built on object storage, priced so that large, rarely queried collections stay inexpensive |
| Where vectors live | In PostgreSQL, beside the application's existing tables | In a dedicated serverless search service on object storage |
| Synchronisation | A row update and its embedding update are one transaction | A pipeline keeps the index in step with the source of truth |
| Cost shape | Part of the database you already pay for | Storage is cheap; you pay mainly when queries run |
| Filtering | Full SQL: joins, subqueries and any predicate Postgres supports | Filtering built into the search service, designed for selective predicates |
| Scale ceiling | Comfortable into the low millions of vectors, competing with application queries | Designed for large corpora and many collections, most of them idle |
| Best fit | Applications on PostgreSQL with a modest corpus | Large or long-tail corpora, especially per-customer indexes |
| Integration path | Python and JavaScript clients over a REST API, with LangChain and LlamaIndex support | Python and JavaScript clients over a REST API, with LangChain and LlamaIndex support |
pgvector
- What it is:
- An extension that adds vector types and indexes to PostgreSQL, so embeddings live beside the application's existing tables
- Where vectors live:
- In PostgreSQL, beside the application's existing tables
- Synchronisation:
- A row update and its embedding update are one transaction
- Cost shape:
- Part of the database you already pay for
- Filtering:
- Full SQL: joins, subqueries and any predicate Postgres supports
- Scale ceiling:
- Comfortable into the low millions of vectors, competing with application queries
- Best fit:
- Applications on PostgreSQL with a modest corpus
- Integration path:
- Python and JavaScript clients over a REST API, with LangChain and LlamaIndex support
Turbopuffer
- What it is:
- A serverless vector and full-text search engine built on object storage, priced so that large, rarely queried collections stay inexpensive
- Where vectors live:
- In a dedicated serverless search service on object storage
- Synchronisation:
- A pipeline keeps the index in step with the source of truth
- Cost shape:
- Storage is cheap; you pay mainly when queries run
- Filtering:
- Filtering built into the search service, designed for selective predicates
- Scale ceiling:
- Designed for large corpora and many collections, most of them idle
- Best fit:
- Large or long-tail corpora, especially per-customer indexes
- Integration path:
- Python and JavaScript clients over a REST API, with LangChain and LlamaIndex support
Public signals
Verified factual signals only. Bars appear only for like-for-like metrics with five weekly assessments for every tool; missing evidence stays explicit. These signals do not establish enterprise adoption, product quality, or total cost.
| Metric | pgvector | Turbopuffer |
|---|---|---|
| Docker Hub pulls(Product adoption) | 194.8M | Not available |
| GitHub commits, 90d(Product adoption) | 153 | Not available |
| GitHub stars(Product adoption) | 23,000+ | Not available |
| Search interest(Market interest) | 3 | 0 |
| Hacker News mentions, 90d(Community interest) | 10 | 11 |
| npm weekly downloads(Developer adoption) | 369.9k | 672.4k |
| PyPI weekly downloads(Developer adoption) | 6.7M | 1.1M |
| Stack Overflow questions(Community interest) | 90 | Not available |
| GitHub commits, 90d(Developer adoption) | Not available | 30 |
| GitHub stars(Developer adoption) | Not available | 169 |
As of September 21, 2026 — updated weekly.
Health & risk evidence
Observed public-source checks for mapped package versions and repositories.
pgvector
September 21, 2026Package vulnerabilities
npm · pgvector@0.3.0 · PyPI · pgvector@0.5.0
0 vulnerabilities
across 2 packages
Repository security score
Not available
Turbopuffer
September 21, 2026Package vulnerabilities
npm · @turbopuffer/turbopuffer@2.9.0 · PyPI · turbopuffer@2.10.1
0 vulnerabilities
across 2 packages
Repository security score
Not available
Interface Preview
Turbopuffer
Feature Comparison
| Feature | pgvector | Turbopuffer |
|---|---|---|
| Architecture | ||
| Vectors beside operational data | Full support | Not verified |
| Transactional updates with the source rows | Full support | Not verified |
| Object storage backed | Not verified | Full support |
| Cost independent of corpus size | Partial support | Full support |
| Query | ||
| Full SQL joins and predicates | Full support | Not verified |
| Filtering with selective predicates | Full support | Full support |
| Hybrid keyword and vector search | Full support | Full support |
| Many isolated collections | Partial support | Full support |
| Operations | ||
| No extra system to run | Full support | Not verified |
| Serverless, nothing to size | Not verified | Full support |
| Independent scaling of the search workload | Not verified | Full support |
| Open source | Full support | Not verified |
| Integration | ||
| Python and JavaScript clients | Full support | Full support |
| REST API | Full support | Full support |
| Metadata stored with vectors | Full support | Full support |
| Works with LangChain and LlamaIndex | Full support | Full support |
Architecture
Vectors beside operational data
Transactional updates with the source rows
Object storage backed
Cost independent of corpus size
Query
Full SQL joins and predicates
Filtering with selective predicates
Hybrid keyword and vector search
Many isolated collections
Operations
No extra system to run
Serverless, nothing to size
Independent scaling of the search workload
Open source
Integration
Python and JavaScript clients
REST API
Metadata stored with vectors
Works with LangChain and LlamaIndex
Which to choose
pgvector and turbopuffer answer opposite ends of the same question. pgvector keeps embeddings in PostgreSQL beside the rows they describe, so updates are transactional, filtering is full SQL, and no new system exists. turbopuffer is a dedicated serverless service on object storage, priced so that large or mostly-idle corpora cost very little to hold.
Best-fit scenarios
Choose pgvector if:
Choose pgvector when the application already runs on PostgreSQL and the corpus is within its comfortable range. Embeddings and rows update together, filtering is the SQL you already write including joins, and there is nothing new to deploy, secure, monitor or back up.
Choose Turbopuffer if:
Choose turbopuffer when the corpus is large or mostly idle, or when search load would compete with the application's own queries. An object-storage index makes tens of millions of vectors — or an index per customer — inexpensive to keep, and the bill follows queries rather than data volume.
These scenarios reflect the available product evidence. Your requirements, existing stack, and team expertise should guide the final decision.
Frequently Asked Questions
When does Postgres stop being enough?
Usually at one of two points: the corpus grows past the low millions and index build or query times become uncomfortable, or search traffic starts competing with the application's own queries on the same instance. Both are measurable rather than theoretical, so instrument before migrating — the answer is often further away than architecture discussions assume.
What fraction of our vectors are searched in a normal day?
It decides how much an object-storage service is worth. If nearly all of the corpus is queried daily, keeping it where the application already is costs little extra. If a small fraction is — per-customer indexes, archived documents, a long tail — the economics shift sharply, because you stop paying to keep cold data in a hot system.
How does filtering work on each?
This is where the two differ most in practice, because almost every real query is "similar to this, and belonging to this customer, and not archived". pgvector filters with Postgres: the predicate is ordinary SQL over ordinary columns with ordinary indexes, and the planner decides whether to filter first or search first — which is powerful and occasionally chooses badly, returning too few neighbours when the predicate is selective. turbopuffer organises data into namespaces, so the common tenant filter becomes a choice of namespace rather than a predicate at all. Test with your most selective filter, not an unfiltered benchmark.
What keeps embeddings in step with the rows they describe?
This is the strongest argument for pgvector and the thing to plan for with turbopuffer. In Postgres the embedding is a column on the row, so updating a document and its vector is one transaction and cannot half-succeed. With a separate store it is a pipeline: a document changes, something must notice, re-embed it and update the index, in order, with retries when the embedding service is slow. That pipeline is ordinary work and it is also the part of a vector deployment that quietly breaks. If your corpus changes constantly, weigh that heavily; if it is rebuilt in batches, it barely matters.
What do these need to run?
An embedding model and a client. Applications in Python or JavaScript call a REST API, embeddings come from an OpenAI, Cohere or open-source model, and the retrieval framework is usually LangChain or LlamaIndex. Self-hosted options run as containers on Docker or Kubernetes with S3 or compatible object storage behind them; managed options need only an API key. The infrastructure is unremarkable — the work is in chunking, embedding choice and keeping the index current.
How should we evaluate them?
With your own corpus and your own queries, measuring recall rather than latency alone. Approximate nearest neighbour search trades accuracy for speed, and the tuning knobs differ between engines, so a fast engine returning worse neighbours looks good on a benchmark and bad to a user. Build a small set of queries with known correct answers, then compare recall at the latency you actually need.