An Archiving Strategy: Old Data Without the Slowdown
Separating old records that bloat the live table: partitioning, cold storage, and keeping query access while you archive
Tag
10 entries: Note, System, Essay.
Separating old records that bloat the live table: partitioning, cold storage, and keeping query access while you archive
On a queue table, an index and an autovacuum threshold that grow with the table scale wrong; the measured case for sizing both to the pending jobs
A missing index slows the query; too many indexes make every write expensive. Striking the right balance by measurement, not by guesswork
Running migrations without causing downtime in production: backward-compatible steps, multi-phase column changes, and avoiding table locks
Before scaling up the database: moving read traffic to replicas, the traps replication lag creates, and when you actually need it
Before adding a separate search engine, queue, or document DB: how far PostgreSQL gets you on its own, and where its limit begins.
As data load grows, where does boring architecture break? Working set, read replicas, partitioning, write load, a separate data layer — in order.
pg_dump alone is not a backup. A PITR-capable, compressed, verifiable backup architecture with pgBackRest.
One VPS, several independent apps. Deliberate minimalism over Kubernetes: user isolation, separate PHP-FPM pools, shared PostgreSQL/Redis, a plain deploy.
A practical setup for dynamic user authentication via `auth_query` instead of `userlist.txt` when running pgBouncer