Four Database Checks to Run Before Black Friday

Your holiday code freeze is probably a week or two out, which means the queries your database runs today are largely the ones it will run at peak, just more of them. The common plan is to scale up the instance and carry that capacity through December. Before committing to that, spend an afternoon finding which queries will be under the most strain. It's usually a short list.

Rank your queries by cumulative execution time

Cumulative execution time is the total a query spends across all its runs. A 40 ms query running tens of thousands of times an hour can consume minutes of core time every hour, and that load multiplies when traffic spikes, while a slow query that runs twice a day stays flat. Check whether a high-total-time query is tied to user requests or a fixed schedule, since an overnight report sits near the top but stays steady through customer traffic. You can use a RDST Desktop agent to monitor and watch your workload to identify your slow queries.

Check your connections and pooling headroom

Many Postgres and MySQL setups hit a connection ceiling well before they run out of CPU. Compare your peak connection count against your configured limit at the database and any pooler in front of it. If your app tier autoscales, multiply the pool size by every app process at peak to see how many connections they can open. If you're close, resist just raising max_connections, since every Postgres connection is its own process and every MySQL connection carries its own buffers. Trimming app pool sizes is usually safer.

Decide when to scale up, and be honest about it

Scaling up is sometimes the right call. If your peak load is primarily write-heavy, a bigger primary can be the most practical option, and if your team has no time to test before the freeze, a month of extra capacity can be the safe choice. If you do scale up, do it before the freeze, since resizing usually means a failover or brief restart. The first two checks tell you whether you need it, or whether most of your peak load is read traffic you could handle more cheaply.

Set up monitoring before the rush

A live view of the right metrics catches a query that slips through before customers do. On the OS side, watch CPU, disk I/O, and free memory so a spike doesn't trip the OOM killer. Inside the database, active queries and open connections move first under load: Threads_running and Threads_connected in MySQL, or active sessions and connection counts in pg_stat_activity for Postgres, plus anything running longer than its normal threshold.

If step one comes back heavy on repeated reads, which it often does for retail, travel, and ticketing, caching those queries takes that load off the database without scaling up. Readyset sits in front of Postgres or MySQL and serves your hottest read queries from a cache it keeps current as the data changes, with no application code changes, so anything it is not certain about goes straight to your database. For a real example, see how Hussle ran their peak-season MySQL load through Readyset.

🔍 What We're Watching in the Database Ecosystem

How a Routine Linux fstrim Job Took Down MySQL: An InnoDB Crash Analysis

A weekly fstrim timer discarded 5.2 TiB of free blocks across three VirtIO volumes, saturating the same queue InnoDB uses for redo log fsyncs. A semaphore wait passed InnoDB's 600-second limit, and InnoDB aborted the server on purpose. Vinoth Kanna walks the diagnosis down from the database to the systemd journal, and notes the storage was thick provisioned, so fstrim had nothing to reclaim in the first place.

PostgreSQL 19: What Changed, What Matters, and What to Test Now

Release candidate one landed October 15, with general availability planned for November 19. Tom Kincaid covers REPACK CONCURRENTLY, the new pg_plan_advice module for constraining planner choices like join order and scan methods, parallel index vacuuming with autovacuum scoring, and sequence synchronization for logical replication. One default worth catching before you test: 19 disables JIT compilation.

In Case You Missed It

Readyset HA with ProxySQL and MySQL

We put a pair of Readyset nodes behind a clustered ProxySQL setup and pointed one 106 ms report query at them. The rewrite everyone asks about first got that query to 88 ms. Readyset got it to 0.716 ms, and the whole change was two docker run commands and two INSERT statements.

We're getting more social, catch the latest on Bluesky, X, dev.to, and Medium too.

Know a database aficionado who'd appreciate this? Forward it their way.