You're building agent memory or RAG retrieval, your corpus is past the "just use Postgres" line, and you've narrowed the shortlist to two object-storage-native engines that keep showing up: LanceDB vs Turbopuffer. Both promise the same headline — vector, full-text, and hybrid search at billion-row scale, with compute separated from storage so your cold data doesn't cost RAM prices. The feature grids look nearly identical.

They aren't. There's exactly one axis that decides this, and it's not on most comparison pages.

The real fork is data gravity: does your data stay an open file you own, or does it live behind one vendor's API? Everything else is downstream of that answer.

The axis that actually matters: who holds the data#

LanceDB writes everything as the open Lance columnar format directly into a bucket you control — S3, GCS, or Azure. That's the whole design philosophy: there is one physical copy of your data, and search, analytics jobs, and any Lance-aware engine you already run all read that same copy. Nothing is trapped. If you want to point a training pipeline or a DuckDB query at the exact bytes your retrieval layer uses, you can.

Turbopuffer also sits on object storage under the hood — that's how it gets the same cheap-cold-data economics — but from your side, the data is reachable only through Turbopuffer's API. That's a clean, managed experience, and it's the right trade for plenty of teams. But it has a consequence worth naming: anything you need beyond what Turbopuffer serves back becomes a second copy of your data, living somewhere else, that you now have to keep in sync.

That single difference propagates into every real decision:

Where each one wins#

Neither of these is a downgrade — they're tuned for different centers of gravity.

Reach for Turbopuffer when your corpus is billions of mostly-cold documents spread across a huge number of tenants — the multi-tenant SaaS shape where keeping everything hot in RAM is absurdly expensive and you want a fully managed service with, effectively, no database to operate. That's the workload it was purpose-built for, and it's excellent at it.

Reach for LanceDB when you want to own the format, when your data is multimodal, or when "no vendor stands between us and our own bytes" is a requirement rather than a preference. The engine and the Lance format are open source (Apache-2.0), with a managed LanceDB Cloud / Enterprise tier when you don't want to run it yourself — so choosing open doesn't mean choosing ops pain.

Both, notably, lean on the same trick for cost: keep cold vectors on object storage instead of in memory and fetch only what a query touches. Vendors on both sides describe this as up to ~100x cheaper than memory-resident vector databases for large, sparse corpora — which is exactly why this whole category exists.

The honest caveat: you might not need either yet#

Before you adopt a dedicated vector engine, check the size of the thing you're actually building. Most AI-agent RAG workloads are smaller than they feel — a few million vectors, comfortably inside what pgvector handles on the Postgres you already run. Running a separate vector database adds operational surface that often doesn't pay back until you cross into tens of millions of rows or genuine multi-tenant sprawl.

So the decision tree is short:

  1. A few million vectors, one tenant? Stay on pgvector. Don't add a system.
  2. Large corpus, and owning an open data format matters? LanceDB.
  3. Billions of cold docs across many tenants, and you want zero DB to run? Turbopuffer.

If you're weighing the managed-vs-serverless end of this market more broadly, we've compared the API-first players in Turbopuffer vs Pinecone vs Vectorize, and the embedded end in LanceDB vs sqlite-vec vs DuckDB. But the LanceDB-vs-Turbopuffer question specifically comes down to one thing, and now you can answer it in a sentence: do you want your retrieval data to be a file you own, or a service you call?