StormaticsStormatics

How Fast Should You Patch Production PostgreSQL?

PostgreSQL's August 2026 release closed 28 CVEs in a single day, a record. The fix itself is a fast binary swap. What actually determines your risk is how long it takes you to apply it. Here's how to set a patch SLA and hit it without breaking production.
Read More

The Right Way to Give a Third-Party DBA Access to Your PostgreSQL Database

Giving an external team access to your PostgreSQL database is one of those decisions that deserves a little thought. The easiest option is to hand over a superuser account, but it's rarely the right one. A better approach is to create a dedicated role with only the privileges they actually need, and it takes just a few minutes to set up. Over the years, I've been on both sides of this conversation. I've been the external DBA being onboarded onto a client's database, and I've been the internal engineer deciding what access to grant. The pattern I'm going to walk you through is the one I'd reach for in either situation: a purpose-built, non-superuser role that gives an outside team exactly what they need to do real work, and nothing they shouldn't have.
Read More

Upgrading PostgreSQL 9.6 to 17 with pg_upgrade

When you are upgrading across major PostgreSQL versions, there are a few ways to go. Dump and restore is the simplest to reason about, but downtime scales directly with database size, so for anything multi-terabyte, it is off the table. Logical replication gets you near-zero downtime, but it only works from PostgreSQL 10 onward; if your source cluster is on less than version 10, that path does not exist in a native way. That leaves pg_upgrade, the community-maintained tool for in-place major version upgrades. With the –link flag, it creates hard links instead of copying data files, so the upgrade step itself stays fast, no matter how big the database is.
Read More

Zero-Pain PostgreSQL DDL Migrations: Avoiding Locks and Long-running Queries in Production

Database migrations are a critical step in the lifecycle of any application, allowing teams to deploy new features, create and change database objects, and scale infrastructure. However, in high-volume mission-critical environments, executing Data Definition Language (DDL) statements can quickly turn into a production nightmare. The primary culprit behind application downtime during DDL deployments is the mismanagement of PostgreSQL's locking mechanism. A single poorly planned ALTER TABLE statement can request an exclusive lock, blocking incoming application queries, exhausting connection pools, causing cascading timeouts, and ultimately leading to revenue loss. To achieve true zero-downtime deployments, database migrations must be fast, defensive, and meticulously designed to avoid heavy locks and long-running queries.
Read More

Archives

Categories