Point-in-Time Recovery in Postgres: The Capability You Hope You Never Use
PITR lets you restore the database to any moment within your retention window. The feature is well-documented; the operational reality is messier.
Notes for the problems that show up after launch: bad plans, awkward migrations, index debt, vacuum pressure, replica lag, and the small decisions that make PostgreSQL easier to operate.
PITR lets you restore the database to any moment within your retention window. The feature is well-documented; the operational reality is messier.
Most teams have backups. Most teams have never restored from one. The first time you test, you find out the backup was missing something.
Logical and physical backups solve different problems. Most teams need both, but only have one. Here is the actual decision framework.
WAL accumulates fast. The retention policy is a tradeoff between PITR window and storage cost. Here is how I think about it.
Pooling is about protecting Postgres from connection shape, not just increasing throughput. The hard parts are transaction mode, prepared statements, bursts, and failure behavior.
Logical replication is more flexible than physical and more fragile. Use it when you need partial replication, cross-version, or selective sync. Don't use it for HA.
Physical replication slots make sure replicas can catch up after a disconnect. They also make sure your primary's disk fills if a replica is gone and forgotten.
Read replicas are eventually consistent. The application's view of "after I wrote, my read should see it" is often wrong by milliseconds, sometimes by minutes.
Failover is mostly fine when you do not need it and broken when you do. Here is how to know which you have.
If your Postgres disk is growing and you cannot identify the culprit, replication slots are usually the answer. Here is the diagnostic sequence.
Most production databases run application traffic as a superuser. This is convenient and wrong. Here is the role hierarchy that takes a few hours to set up and saves you in the worst case.
Replication monitoring is not one lag number. You need to know stale-read risk, slot retention, replay delay, WAL growth, and whether failover would help or hurt.