Scale split between pgvector and turbopuffer

This recommendation shows that turbopuffer is not trying to replace Postgres at the low end, it is trying to win the moment when Postgres stops being the simplest place to keep retrieval. Below that scale, pgvector lets a team store app rows and embeddings in the same database, run joins against live product data, recover with normal Postgres backups, and avoid building a second ingestion and consistency pipeline just for search.

• The real switching cost is operational, not just vendor choice. Moving from pgvector to turbopuffer means reshaping data for object storage, dual writing during migration, and keeping search state in sync with the transactional source of truth so users do not see stale or missing results.
  2 sacra 3 sacra
• The payoff starts when corpus size and access patterns get weird. turbopuffer is built for billions of mostly cold documents and huge namespace counts, where keeping everything hot in memory gets expensive. That is a very different workload from a typical product team storing a few million vectors beside application tables.
  2 sacra 4 sacra
• This also explains why open source pressure is strong in the category. pgvector rides on Postgres adoption, and LanceDB appeals to teams that want open source software and file portability on object storage, so turbopuffer has to win on managed performance and economics rather than basic vector search availability.
  3 sacra 5 sacra 6 lancedb

Going forward, vector infrastructure will split more clearly by workload. Postgres extensions will keep absorbing small and medium retrieval use cases, while object storage native systems like turbopuffer will concentrate around very large, sparse, multi tenant corpora where storage cost and namespace scale matter more than keeping everything inside one database.