~/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.

production-stack.manifest

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 in front, 10k pooled to 200 backend, transaction pooling mode by default, session pooling available per-database.

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

7-day PITR, continuous WAL archiving, sub-second RPO.

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

HA cluster with streaming replication and automatic failover, separate read-only connection string for offloading analytics.

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 0.8 pre-installed, recall@10 ≈ 0.97 out of the box on a 50M-vector workload.

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.

p99 < 40 ms

read latency on a 50M-vector HNSW index

0.97

recall@10 with default HNSW parameters (m=16, ef=64)

10k → 200

pooled to backend connection saturation headroom

# what "managed Postgres" usually ships, and what Rivestack ships

Pooler
typical managed PostgresSold separately or premium add-on
rivestackIncluded, PgBouncer pre-configured
PITR retention
typical managed Postgres1 to 3 days at base tier
rivestack7 days default
HA + automatic failover
typical managed PostgresHigher tier only
rivestackHA cluster, Patroni-managed failover
pgvector version
typical managed PostgresOften lags upstream by months
rivestackLatest stable (0.8)
Per-database metrics
typical managed PostgresAccount-wide only or add-on
rivestackBuilt-in dashboard per database
pg_stat_statements
typical managed PostgresSometimes disabled
rivestackEnabled by default
Autovacuum tuning
typical managed PostgresDefault knobs, no per-table tuning
rivestackPer-table tuning supported

# faq

Yes. Logical replication from any Postgres 14+ source, or pg_dump + restore for smaller datasets. Migration window is typically 30 to 60 minutes for databases under 500 GB.

Yes. Free dev tier with 2 GB storage, no credit card. Start free.

Tune HNSW parameters, add HA standbys for automatic failover, switch pooling modes without downtime, or migrate to a larger node. Nothing is locked.

$ ready to skip the 5-step checklist?

// Free database in seconds. Full HA cluster in under 10 minutes. pgvector 0.8, pooler, PITR, HA, metrics, all included in the default.