Should I store embeddings in PostgreSQL or a separate vector DB?

It depends mostly on scale, latency, and how much you want to operate.

Short answer

• Use PostgreSQL (with pgvector) if you want simplicity, strong transactional consistency, and your vector workload is moderate.
• Use a separate vector DB if you need very high-scale vector search, low-latency retrieval under heavy load, or advanced ANN/vector-search features and tuning.

PostgreSQL is a good choice when

• You already use Postgres as your main database
• You want one system for metadata + embeddings
• Your dataset is small to medium or growth is predictable
• You care about:
  • ACID transactions
  • joins with app data
  • easier backups/ops
  • fewer moving parts
• Your search requirements are mostly:
  • “find similar items”
  • “filter by metadata and then search vectors”
  • modest query volume

Pros

• Simpler architecture
• Easier to keep embeddings synchronized with source data
• Great for hybrid queries with metadata filters
• Lower operational overhead

Cons

• Vector search performance/scaling can lag specialized systems at large scale
• Index tuning and query performance may become limiting
• Less purpose-built for high-dimensional ANN workloads

Separate vector DB is a good choice when

• You expect large embedding volumes or rapid growth
• You need high QPS and low latency for similarity search
• Your team wants vector-search-specific features like:
  • multiple ANN index types
  • recall/latency tuning
  • namespaces/collections optimized for embeddings
  • built-in reranking or hybrid retrieval features
• You want to decouple the vector workload from OLTP traffic

Pros

• Better performance at scale
• Purpose-built for ANN/vector retrieval
• Easier to optimize for search use cases
• Can isolate vector workload from transactional DB load

Cons

• More infrastructure and operational complexity
• Need to keep data synchronized between systems
• Two sources of truth can create consistency issues
• Usually extra cost

A practical rule of thumb

Choose Postgres + pgvector if:

• You’re under roughly millions of vectors rather than tens/hundreds of millions
• Your latency requirements are reasonable, not ultra-strict
• You want a simple, reliable default

Choose a vector DB if:

• You’re building a search-heavy product
• You have large-scale retrieval
• You need to serve many similarity queries concurrently
• You’ve already hit performance limits in Postgres

Common architecture pattern

A lot of teams do:

• Postgres for app data, permissions, metadata, and source of truth
• Vector DB for embeddings/search
• Optionally keep a lightweight embedding pointer/id in Postgres

That said, if your use case is still early-stage, starting with Postgres + pgvector is often the best move. You can always migrate later if needed.

My recommendation

• Start with PostgreSQL/pgvector unless you already know you need serious scale or specialized vector-search performance.
• Move to a vector DB when:
  • queries get too slow
  • indexing becomes painful
  • operational load increases
  • you need advanced retrieval features

If you want, I can help you choose based on your specific situation—e.g.:

• number of vectors
• embedding dimension
• query rate
• filter complexity
• expected growth