18 August 2026

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

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

Alexander Ioffe: What Does a Covering Index Cost You?

Quantifies the write overhead of covering indexes on PostgreSQL 17 using a 2-million-row dataset. It shows that while reads are 1.26x faster, INSERTs and UPDATEs slow down by 28% and 25% respectively, meaning covering indexes only yield a net benefit below approximately 4,300 writes per analytical read.

Why it matters — Covering indexes impose a measurable write penalty (+28% on INSERTs, +25% on UPDATEs) that only pays off if the write-to-analytical-read ratio is below ~4,300.

Planet PostgreSQL · 18 August 2026 · Read the original →

Performance

Alexander Ioffe: Why Does PostgreSQL Skip My Index?

Explains how PostgreSQL's default cost model parameters, specifically random_page_cost = 4.0, are optimized for legacy spinning disks and cause the planner to ignore valid indexes on modern SSDs. Adjusting this parameter to 1.1 allowed a sample query's execution time to drop from 125.98ms to 68.69ms.

Why it matters — The default random_page_cost of 4.0 is outdated for SSDs; lowering it to 1.1 aligns the planner with modern hardware performance and prevents it from skipping indexes.

Planet PostgreSQL · 18 August 2026 · Read the original →

Data Engineering

Model for the token, not the table

Details how restructuring raw Gong API transcript data within a data warehouse using dbt optimized the data payload for LLM consumption. By modeling specifically for token efficiency rather than traditional tabular structures, the team reduced their LLM token costs by 20x.

Why it matters — Modeling warehouse data specifically to minimize LLM token footprints rather than adhering to traditional database normalization can reduce API costs by up to 20x.

dbt · 18 August 2026 · Read the original →

Reliability

Ajin Cherian: Failover slot synchronization in PostgreSQL

Explores PostgreSQL 17's new failover slot synchronization feature, which keeps logical replication slots synchronized on standby servers. This prevents subscribers from losing their replication progress and needing a full resynchronization when a standby is promoted to primary.

Why it matters — PostgreSQL 17's failover slot synchronization maintains logical replication slot states on standbys, preventing expensive subscriber resynchronizations during failover.

Planet PostgreSQL · 18 August 2026 · Read the original →

Analytics & OLAP

How iFood built its agentic security platform on ClickHouse Cloud

A case study of iFood migrating its security platform to ClickHouse Cloud to handle high-volume telemetry. The migration resulted in query performance improvements of 9x to 16x while reducing infrastructure costs by 40% to 50%.

Why it matters — Migrating high-volume security telemetry to ClickHouse Cloud cut costs by 40-50% while accelerating queries by up to 16x.

ClickHouse · 18 August 2026 · Read the original →

Data Engineering

How dbt State cuts warehouse compute and speeds up every run

Demonstrates how Fanatics optimized their data pipeline execution times and warehouse spend using dbt State. By leveraging state comparison to identify and rebuild only modified models and their downstream dependencies, they significantly reduced compute consumption.

Why it matters — Using dbt State to perform incremental, impact-aware runs instead of full rebuilds directly reduces warehouse compute costs.

dbt · 18 August 2026 · Read the original →

Vector & AI Data

Reciprocal rank fusion: why combining search results is harder than it looks

Explains the challenges of merging traditional keyword search results (BM25 scores) with vector search results (cosine similarity) into a single, cohesive ranking. It details how Reciprocal Rank Fusion (RRF) bypasses the problem of uncalibrated raw scores by using rank position instead of raw scores.

Why it matters — Reciprocal Rank Fusion (RRF) normalizes and merges disparate search scoring systems (like BM25 and vector similarity) by prioritizing rank order over raw scores.

Redis · 18 August 2026 · Read the original →

Data Engineering

Agentic Infrastructure with ClickHousectl

A multi-region observability platform was built using `clickhousectl` and ClickHouse Cloud across the US, Europe, and Japan. Each region ingests its own OpenTelemetry logs, traces, and metrics, with a global view consolidated in Europe. This architecture allows for distributed storage while providing a single pane of glass for operational health.

Why it matters — Deploying a multi-region observability platform with ClickHouse Cloud and `clickhousectl` enables regional data ingestion and a single global view for operational insights.

ClickHouse · 18 August 2026 · Read the original →

At least the agents will also have to debug why Postgres skipped their index.

8 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 →