Advisory Locks in Postgres: A Simple Tool That Deserves Respect
Advisory locks are useful precisely because Postgres does not know what they mean. They give you cross-process coordination that does not depend on rows.
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.
Advisory locks are useful precisely because Postgres does not know what they mean. They give you cross-process coordination that does not depend on rows.
Arrays are a Postgres feature that can simplify code and a feature that can lock you into bad design. Here is the rule I use to decide when to reach for them.
JSONB is great for things that genuinely vary per row. It is wrong for things that are stable. Most teams use it for both, and pay for it in queries that should have been simple.
WAL is fine when it is fine and a crisis when it is not. Three signals tell you the difference, and they are not the ones the dashboards usually surface.
Storing money as `DOUBLE PRECISION` is one of the bugs that takes years to surface. The numbers look right until they don't.
Postgres full-text search is great for the cases it covers and frustrating for the cases it doesn't. Knowing where the line is saves a year of trying to make it do what Elasticsearch does.
CITEXT is the type for text columns where case should not matter. It is simpler than expression indexes, more reliable than application-level normalization.
Range types model time windows, numeric ranges, and any "from-to" data. They support overlap queries natively and combine with EXCLUDE constraints to prevent invalid data.
Materialized views trade staleness for query speed. The tradeoff is right when the underlying data changes slowly and the query is expensive.
Rollup tables are pre-aggregated summaries of source data, kept up to date via triggers or scheduled jobs. They turn dashboard queries from seconds into milliseconds.
Latency climbs for 30 seconds, then recovers. CPU is fine. Queries are fine. Nobody deployed anything. Welcome to the checkpoint problem, and the four settings that make it go away.
Postgres handles time-series data better than people assume. The decision to add a specialized extension should come from observed limits, not preemptive optimization.