Managed pgvector hosting
on dedicated NVMe.

Managed pgvector means PostgreSQL with the pgvector extension pre-installed, pre-tuned, and operated for you on dedicated infrastructure. You get the standard pgvector SQL surface — the vector type, HNSW and IVFFlat indexes, distance operators — on top of a database where someone else handles backups, monitoring, replication, failover, and version upgrades. On Rivestack specifically, that infrastructure is local NVMe rather than cloud SSD, which is what HNSW random-read workloads care about most.

Yes. pgvector is used in production for RAG, semantic search, recommendation engines, and embedding search APIs with millions of vectors. The constraints to plan for are memory headroom for the HNSW index, storage latency on cache misses, sensible ef_search and m values, and proper filtering — usually B-tree indexes on the columns used in WHERE alongside the HNSW index. PostgreSQL handles the rest with the same backup, replication, monitoring, and tuning patterns it has used for years.

A well-sized PostgreSQL node handles tens of millions of vectors comfortably; hundreds of millions are reachable with sharding or partitioning. The practical limits are memory available for the HNSW index, storage IOPS under random reads, and how strict your latency targets are. As a rough guide on Rivestack: a 4 GB node serves around 1M 1536-dimension vectors with sub-10ms p95 latency at moderate concurrency, and a 16 GB node serves around 20M.

HNSW (Hierarchical Navigable Small World) is the graph-based approximate nearest neighbor index pgvector uses for fast vector search. Build-time parameters m and ef_construction control graph density; the query-time parameter hnsw.ef_search controls how aggressively the graph is traversed. Higher values mean better recall and slightly higher latency. HNSW search is dominated by random reads, which is why storage latency matters more than CPU once the index no longer fits in memory.

For most teams, yes. pgvector keeps vectors next to the relational data, so filters, joins, and tenant scoping happen in standard SQL — without a second system to keep in sync. Dedicated vector databases still make sense at very large scale (hundreds of millions to billions of vectors) or when the workload is purely vector search with no relational context. For typical RAG and semantic search systems, pgvector on managed PostgreSQL is simpler and cheaper.

Start with the workload, not the provider list. The questions that actually decide it: what storage latency the plan delivers under random reads, how much memory is available for the HNSW index plus PostgreSQL cache, which pgvector version is supported and how upgrades happen, what backup and PITR coverage is included, what the HA topology looks like, how pricing changes when query volume grows, and how the provider helps you migrate from where you are today. A provider that can answer those in workload language is a real candidate.

On a $35/month Rivestack node we measure up to about 2,000 QPS on cached vector workloads, and sub-4ms p50 on the 1M × 1536-dim HNSW benchmark path. Tail latency depends on concurrency, cache residency, filters, and ef_search; the benchmark section shows p99 separately instead of compressing every latency percentile into one marketing number. Full methodology is in the pgvector NVMe vs cloud SSD writeup.

Yes. Supabase and Neon are standard PostgreSQL with pgvector, so migration is pg_dump / pg_restore for smaller databases or logical replication for always-on workloads — typically 30–60 minutes of effort, no application changes. Pinecone is not Postgres, so you re-insert your embeddings into a vector column once; we have a migration helper and we will look at your workload shape before you start.

Rivestack tracks the pgvector 0.8.x release line and rolls extension updates through standard maintenance windows after compatibility testing. New clusters are provisioned with the supported 0.8.x build; existing clusters are upgraded deliberately rather than silently.

Yes. pgvector 0.8.x supports PostgreSQL 13 through 18. Rivestack provisions every cluster on PostgreSQL 18 with pgvector pre-installed, so you can use the latest planner, partitioning, and observability improvements alongside vector search without managing extension compatibility yourself.

Both. HNSW is the default and what we tune for, because it is the right choice for almost every production workload at the scale our customers run. IVFFlat is fully supported when you have a static dataset and want lower index build time and lower memory. You can mix both index types within the same database.