Logical Replication in Postgres: When It Is the Right Tool and When It Isn't
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.
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.
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 health is more than a lag number. Watch replay delay, slot retention, WAL growth, sync state, and the product impact of stale reads.
RLS pushes access control into the database. It is more secure than application-side filters and slightly slower than no filter at all. Here is the framework for using it well.
SSL on Postgres is a one-line config change to enable and a multi-day project to do correctly. The default settings are not good enough.
"Did anyone read the customer table outside expected hours" is a common audit question. The answer is harder to produce than it should be unless you set up auditing deliberately.
Most Postgres connection strings live in places they should not. Environment variables, config files, scripts, screenshots in Slack. Here is the discipline.
RDS exposes hundreds of Postgres parameters through Parameter Groups. About a dozen of them are worth tuning. Here are the ones I always change and why.