PostgreSQL for AI —
one database for data and vectors.

Yes. With the pgvector extension, PostgreSQL stores and searches high-dimensional embeddings using HNSW and IVFFlat indexes — the core of retrieval-augmented generation (RAG), semantic search, and recommendation systems. Because the vectors live next to your relational data, you filter, join, and scope by tenant in standard SQL without running a separate vector database.

For most teams PostgreSQL is the simpler and cheaper choice. RAG retrieval is nearest-neighbour search with filters, which pgvector handles well into the tens of millions of vectors. A dedicated vector database earns its keep at very large scale (hundreds of millions to billions of vectors) or when the workload is pure vector search with no relational context. If your AI feature also needs users, documents, permissions, or metadata, keeping it all in Postgres removes an entire system from your stack.

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

Any of them. pgvector stores a plain array of floats, so embeddings from OpenAI, Cohere, Voyage, Google, or your own open-source model all work — you just match the vector column dimension to the model output (for example vector(1536) for OpenAI text-embedding-3-small). You can keep multiple embedding columns in one table if you run more than one model.

You do not have to. That is the main advantage of PostgreSQL for AI: the embedding is a column on the same row as the content, written in the same transaction. There is no second datastore to dual-write, no eventual-consistency window, and no reconciliation job. When you delete or update a record, its vector goes with it.

Yes, and more cleanly than vector-only databases. Because filtering is just a SQL WHERE clause, you combine vector similarity with B-tree indexes on the columns you filter on — tenant_id, language, document type, recency — in one query plan. This avoids the "filter then search" vs "search then filter" trade-offs that pure vector stores expose.

HNSW graph traversal is dominated by random reads once the index no longer fits in RAM. Local NVMe delivers far lower random-read latency than general-purpose cloud block storage, which is exactly what tail latency on vector search depends on. On Rivestack we measure sub-4ms p50 on a 1M × 1536-dim HNSW path; the full methodology is in the NVMe vs cloud SSD benchmark.

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 with no application changes. Pinecone is not Postgres, so you re-insert your embeddings into a vector column once; we help map your metadata filters back to SQL columns before you start.

Yes. Both frameworks ship first-class PGVector vector stores — point them at your Rivestack connection string and they handle inserts and similarity queries for you. Because it is plain PostgreSQL underneath, you can also drop to raw SQL whenever you need joins or filters the framework abstraction does not expose.

A dedicated Rivestack VM with pgvector, NVMe, and daily backups starts at $15/month (Solo) — flat, not metered by query volume. The free tier is enough to prototype RAG and semantic search at no cost. There is no per-query or per-vector billing, so cost stays predictable as your AI feature scales.