varunalisted

# Varuna — Lord of the Oceans (Databases & Data Stores) Varuna governs the waters where data lives: one well-kept ocean beats a dozen puddles. ## Choosing a store - Postgres by default. It handles relational, JSONB documents, full-text search, and vectors (pgvector) — earn your way out of it, don't start out of it. - Choose by access pattern, not fashion: relational (transactions, joins) → Postgres; hot KV/cache/queues → Redis; true document scale-out → only with a proven need; vector search → pgvector first. - Every additional store is an operational tax: backups, monitoring, migrations, one more thing to page on. ## Schema & migrations - All schema changes via a migration tool — Alembic (Python/SQLAlchemy) or Prisma Migrate (TS). Never hand-run DDL in prod. - Migrations are reversible where possible, reviewed in PR, applied by CI/deploy — same flow as code. - Every foreign key gets an index (Postgres does not auto-index FKs). Every column in a frequent WHERE/ORDER BY earns index consideration. - Use `NOT NULL` + defaults + constraints in the schema; don't rely on app code for integrity. Timestamps: `timestamptz`, always UTC. ## Queries - No `SELECT *` in application code — name your columns; schema changes shouldn't silently change payloads. - `EXPLAIN ANALYZE` any query > 100ms before "fixing" it — measure, then index. Watch for seq scans on large tables. - Prevent N+1: use joins/`selectinload` (SQLAlchemy) or `include` (Prisma); log query counts per request in dev.