25 August 2026

53 new posts across 9 database and data engineering sources — 7 worth your time.

One week of Databases & Data, 7 stories, as published.

Jeremy Schneider: Why Postgres Breaks Kubernetes container_memory_working_set_bytes Metric

Explains why the Kubernetes metric 'container_memory_working_set_bytes' is highly inaccurate for monitoring PostgreSQL memory usage. The metric, which Kubernetes uses to trigger pod evictions, includes inactive file cache memory from cgroups v2, leading to false OOM kills when Postgres performs heavy disk I/O.

Why it matters — Kubernetes' eviction logic treats reclaimable inactive file cache as active usage, meaning database pods can be killed prematurely unless memory requests and limits are set identically or cgroup behavior is accounted for.

Planet PostgreSQL · 25 August 2026 · Read the original →

Reliability

Poisoned Postgres connection pools

Explains the phenomenon of 'poisoned' connection pools in PostgreSQL, where session-level state changes or uncommitted transactions leak back into the pool. This can cause subsequent queries on the same connection to fail or behave unexpectedly, potentially taking down an entire application.

Why it matters — Session-level configurations persist across connection reuse in a pool unless explicitly reset, requiring poolers to be configured with proper cleanup or discard commands to prevent silent state leakage.

PlanetScale · 25 August 2026 · Read the original →

Performance

Christophe Pettus: The Sixth Execution

Details how PostgreSQL prepared statements automatically switch from custom query plans to generic query plans on their sixth execution. This switch can cause sudden, mysterious query slowdowns if the generic plan is poorly optimized for the specific parameters being passed.

Why it matters — PostgreSQL prepared statements switch to generic plans on the sixth execution, which can be overridden using the 'plan_cache_mode' setting to force custom plans when parameter distribution varies wildly.

Planet PostgreSQL · 25 August 2026 · Read the original →

Reliability

What else runs on your Postgres server, and how do we stop it from taking the database down?

Describes the mechanisms ClickHouse Managed Postgres uses to prevent supporting services (like backup agents or logging daemons) from compromising database availability. It details the use of cgroup limits, runtime budgets, and disk-full session exemptions to isolate resources.

Why it matters — Implementing disk-full session exemptions allows administrators to connect and run cleanup commands even when the disk is at 100% capacity and rejecting standard connections.

ClickHouse · 25 August 2026 · Read the original →

Performance

Chunked Query Results in the DuckDB Java Driver

Explores how the DuckDB Java driver bridges the gap between DuckDB's vectorized execution engine (which processes data in chunks of 2,048 rows) and JDBC's legacy row-by-row ResultSet API. It details how chunked query results avoid the overhead of materializing entire result sets in memory.

Why it matters — Vectorized databases must carefully design their driver interfaces to avoid converting columnar chunks into row-based objects prematurely, which destroys the performance benefits of vectorized execution.

DuckDB · 25 August 2026 · Read the original →

Analytics & OLAP

Shopify powers observability for global-scale commerce with ClickHouse

Outlines how Shopify migrated and unified its global-scale observability infrastructure onto ClickHouse. The new architecture handles peak ingestion rates of 100 million events per second while delivering up to 30x faster query performance compared to their previous setup.

Why it matters — Consolidating fragmented storage engines into a single columnar store can simultaneously reduce operational complexity and drastically lower query latencies at extreme scale.

ClickHouse · 25 August 2026 · Read the original →

Practice

Mikhail Shytsko: The Postgres Insert That Fails Right After a Successful Load

Explains a common failure scenario where a bulk data load (using tools like COPY) succeeds, but subsequent application inserts fail with duplicate key errors. This occurs because bulk loading bypasses the automatic incrementing of PostgreSQL sequences, leaving them out of sync with the actual table data.

Why it matters — Bulk data imports that specify primary key IDs manually bypass sequence increments, requiring an explicit 'setval' update to prevent subsequent application write failures.

Planet PostgreSQL · 25 August 2026 · Read the original →

Eventually, every engineering problem becomes a Postgres configuration issue.

7 stories, every Tuesday

Published here every week. Follow by RSS to get it as it lands.

Subscribe by RSS All issues

← Previous issue Next issue →