Ardent Performance Computing
database
Why Postgres Breaks Kubernetes container_memory_working_set_bytes Metric
Kubernetes metric container_memory_working_set_bytes is used for evicting/killing pods with too much memory use, especially if memory request < limit (don’t do this with Postgres). The metric is calculated from cgroups v2 memory.stat as current-inactive_file [source]. You’d assume it’s a good metric for memory usage in kubernetes. But with Postgres, this metric is very inaccurate for … Continue reading
Postgres Checkpoint Followup and Collation Visualization and Codex Luna
My previous article talked about the checkpoint happiness hint: You probably should not change the checkpoint_timeout setting from its default of 5 minutes. Checkpoint Followup Questions A good follow-up question was raised: can an HA replica can save you from downtime if you want to set a large checkpoint_timeout? It’s true that Postgres allows promoting … Continue reading
Happiness Hint: Alarm on Checkpoint Time
Before starting, I want to put a few things at the top: Checkpoint is the heart of your database. It’s buried deep inside. It’s not something everyone talks about, like well-tuned autovacuum or fast queries. But if checkpointer stops beating, then you’re dead. In addition to its well-understood job of getting dirty pages written from … Continue reading
Zero autovacuum_vacuum_cost_delay, Write Storms, and You
A few days ago, Shaun Thomas published an article over on the pgEdge blog called [Checkpoints, Write Storms, and You]. I left a few comments [on LinkedIn]. This article is a great technical read about an important and overlooked topic – and I always love seeing real test results to illustrate the details. I don’t … Continue reading
Database Schema Migrations in 2026 – Survey
What is the best way to manage database schema migrations in 2026? Since this sort of thing is getting easier with AI tooling, I spent some time doing a survey across a bunch of recognizable multi-contributor open source projects to see how they do database schema change management. Biggest takeaway: the framework provided by your … Continue reading
Postgres client_connection_check_interval
Saw this post on LinkedIn yesterday: I also somehow missed this setting for years. And it’s crazy timing, because it’s right after I published a blog about seeing the exact problem this solves. In my blog post I mentioned “unexpected behaviors (bugs?) in… Postgres itself.” Turns out Postgres already has the fix; it’s just disabled … Continue reading
How Blocking-Lock Brownouts Can Escalate from Row-Level to Complete System Outages
This article is a shortened version. For the full writeup, go to https://github.com/ardentperf/pg-idle-test/tree/main/conn_exhaustion This test suite demonstrates a failure mode when application bugs which poison connection pools collide with PgBouncers that are missing peer config and positioned behind a load balancer. PgBouncer’s peering feature (added with v1.19 in 2023) should be configured if multiple PgBouncers are being used … Continue reading
Postgres Booth at PASS Data Community Summit
PASS Data Community Summit 2025 wrapped up last week. This conference originated 25 years ago with the independent, user-led, not-for-profit “Professional Association for SQL Server (PASS)” and the annual summit in Seattle continues to attract thousands of database professionals each year. After the pandemic it was reorganized and broadened as a “Data Community” event, including … Continue reading
KubeCon 2025: Bookmarks on Memory and Postgres
Just got home from KubeCon. One of my big goals for the trip was to make some progress in a few areas of postgres and kubernetes – primarily around allowing more flexible use of the linux page cache and avoiding OOM kills with less hardware overprovisioning. When I look at Postgres on Kubernetes, I think … Continue reading
Explaining IPC:SyncRep – Postgres Sync Replication is Not Actually Sync Replication
Postgres database-level “synchronous replication” does not actually mean the replication is synchronous. It’s a bit of a lie really. The replication is actually – always – asynchronous. What it actually means is “when the client issues a COMMIT then pause until we know the transaction is replicated.” In fact the primary writer database doesn’t need … Continue reading
Disclaimer
This is my personal website. The views expressed here are mine alone and may not reflect the views of my employer.
contact: schneider @ ardentperf.com
Ardent Performance Computing 
Recent Comments