proomt

Search

Search posts, papers, and topics

All posts

ClickHouseKaushik Iska8 min readintermediate

Postgres on NVMe: performance and the convergence of transactions and analytics

Read on clickhouse.com

Summary

Local NVMe storage cuts Postgres I/O latency from ms to µs, yielding ~9× higher TPS and 10× lower transaction latency on a 482 GiB pgbench workload. The gain comes from reduced IO wait, not more CPU work. To retain durability, combine NVMe with quorum synchronous replication and continuous WAL archiving (WAL‑G). For analytics, offload scans to ClickHouse via WAL‑based CDC (pg_clickhouse or the ne…

  • When the working set exceeds RAM, storage latency dominates Postgres performance.
  • Instance‑store NVMe (tens of µs) behaves like a second memory tier, dramatically improving OLTP latency and throughput.
  • Benchmark: 16 030 TPS / 4.0 ms per UPDATE on NVMe vs 1 734 TPS / 36.9 ms on gp3 EBS (8‑node cluster, 64 clients).
  • NVMe reduces I/O wait; CPU utilization rises but overall wall‑time drops.

High‑throughput payment and SaaS workloads often hit storage bottlenecks as data grows to hundreds of GBs. Switching to local NVMe can turn a latency‑bound system into a predictable, high‑TPS service without major code changes, but you still need a separate columnar engine for heavy analytics.

8/10
storageperformancepostgresanalyticsreplicationcdc

Related reading

  1. Postgres week in the Netherlands: PGDay Lowlands & Percona Live 2026

    The author recaps two Dutch conferences where they presented ClickHouse‑Postgres extensions and discussed PostgreSQL 19 monitoring enhancements. The post explains how pg_clickhouse provides transparent query push‑down to ClickHouse and how pg_stat_ch streams per‑query metrics, plus new logging defaults and system views in PG 19.

    ClickHouseclickhouse.com7 min

  2. pgAssistant 3.8.0 : continuous improvement loop for Postgres

    pgAssistant 3.8.0 expands from a tuning advisor to a continuous PostgreSQL improvement platform, adding a Collector that records historical workload and environment data. It lets teams run an Observe‑Diagnose‑Prioritize‑Plan‑Implement‑Measure loop, compare consecutive snapshots, and measure the impact of applied recommendations.

    PostgreSQLpostgresql.org1 minrelease

  3. Running OpenBao on Kubernetes with a CloudNativePG PostgreSQL backend

    Step‑by‑step recipe to run OpenBao (Vault fork) on Kubernetes using CloudNativePG as a password‑less, TLS‑authenticated PostgreSQL storage backend. Shows how to spin up a Kind cluster with the cnpg‑playground, deploy a 3‑node CNPG cluster with synchronous quorum replication, configure DatabaseRole‑based client certificates, set up pg_hba rules, and initialize OpenBao’s schema via a one‑off Job.

    CNCFcncf.io16 minHN2

  4. Training a 4B model to produce 81% faster query plans than Postgres

    A 4‑billion‑parameter open‑weight LLM, fine‑tuned with supervised learning and a custom RL loop, learns to emit PostgreSQL join plans that cut query latency by 44.7 % on a 113‑query benchmark. The author built a low‑noise measurement harness, a GRPO‑style reward function, and ran off‑policy distillation from ~500 GPT‑6‑style trajectories, demonstrating that a modest model can outperform Postgres’…

    Hacker News front pagerohanbansal.com51 minHN692143

  5. Blocking cutovers to save replication slots

    PlanetScale’s Postgres operator blocks cutovers that would leave logical replication slots out‑of‑sync. By requiring `failover=true` on slots and turning on `hot_standby_feedback` and `sync_replication_slots`, the operator ensures slots survive a primary promotion, preventing downstream CDC consumers from losing data.

    PlanetScaleplanetscale.com5 min

  6. Introducing TIN: full-text search for Postgres

    PlanetScale’s TIN is a new PostgreSQL extension that implements a full‑text search index supporting Boolean, phrase, span, fuzzy, wildcard, regex, case/accent folding, COUNT(*) and BM25 top‑k queries. In a suite of benchmarks on an i7i.8xlarge EC2 instance (8 vCPU, 32 GB RAM), TIN built in 8 min 10 s (50.7 GB index) and outperformed ParadeDB, pg_textsearch and the built‑in GIN index by large marg…

    PlanetScaleplanetscale.com15 minHN20175