~/pgvector $ _
the production checklist · pgvector 0.8
The pgvector production
stack, disassembled.
Most pgvector tutorials stop at CREATE INDEX USING hnsw. Here are the 5 pieces you actually need once you cross 10M embeddings.
stack> ls --production_
✓Pooler
✓Point-in-Time Recovery (PITR)
✓High availability
✓Index tuning
✓Monitoring
5 components · all included by default
The tutorial ships one line. Production ships five. Everything below is on by default.
the 5 things that break at scale
Each item: what breaks if you skip it, and how Rivestack handles it by default.
Pooler
what breaks
A 10k-connection spike from embedder workers crashes Postgres directly. Connection storms take the DB down before your app layer notices.
rivestack default
PgBouncer on port 6432 with transaction pooling by default. Backend pool and client admission limits are sized to the selected node.
Point-in-Time Recovery (PITR)
what breaks
"Daily backups" only recover you to yesterday. A dropped table at 4pm loses a day of writes. PITR with continuous WAL archiving recovers to any second in the retention window.
rivestack default
Daily full backups, continuous WAL archiving, and 7-day Solo or 14-day HA retention. Recovery depends on the last WAL segment archived successfully.
High availability
what breaks
A single-node database is a single point of failure. Read traffic on the primary starves the write path. Vector queries with large ef values lock up connections analytics dashboards need.
rivestack default
Clusters with 2 or more nodes use asynchronous streaming replication and Patroni-managed failover. One stable endpoint routes to the primary; applications reconnect after a failover.
Index tuning
what breaks
Default HNSW parameters (m=16, ef_construction=64) are a starting point, not a destination. Under-tuned = poor recall. Over-tuned = slow builds and high RAM.
rivestack default
pgvector and pgvectorscale are enabled by default. Choose HNSW, IVFFlat, or StreamingDiskANN from measurements on your own embeddings and filters.
Monitoring
what breaks
You can't tune what you can't see. The first time you hear about replica lag is when a user complains about stale data.
rivestack default
Built-in metrics dashboard per database: CPU, memory, connections, replica lag, query throughput, pg_stat_statements and slow query log enabled.
how the defaults hold up
Numbers from the default Rivestack configuration. No custom tuning required.
~1,600 QPS
measured on Starter at 250k × 1536 dimensions, 16 clients
~0.93
recall@10 in that measured HNSW run
0.4–0.9 ms
historical same-region SELECT 1 floor; remeasure the current path
what "managed Postgres" usually ships, and what Rivestack ships
faq
Yes. The dashboard migration workflow uses PostgreSQL dump and restore. Duration and cutover planning depend on database size, network throughput, extensions, and write activity, so test a representative migration before scheduling production cutover.
Yes. New customers (no previous Rivestack subscription) get a 7-day free trial on Solo. A card is required at checkout; cancel before the trial ends and you pay nothing. Start free trial.
Tune index parameters, evaluate StreamingDiskANN, add standbys for automatic failover, or move to a larger node. Plan for reconnects whenever a topology or pooling change affects live connections.
Ready to skip the 5-step checklist?
Start with pgvector and pgvectorscale enabled. Dedicated plans add pooling and backups; choose 2 or more nodes when you need automatic failover.