The HTAP Dream Keeps Coming Back

In the space of a few weeks in 2025, two of the biggest names in analytics bought a transactional database. Databricks acquired Neon for about a billion dollars in May, and Snowflake acquired Crunchy Data for around $250 million in June. Both companies build analytics platforms, and both decided they needed Postgres under the hood. Around the same time, a wave of open-source extensions (pg_duckdb, pg_lake, pg_mooncake) started stitching DuckDB's analytics engine into Postgres from the other direction. The pattern underneath this is an old idea with a new round of momentum: run analytics and transactions on one system instead of two.

The industry calls that goal HTAP, hybrid transactional/analytical processing, and has been chasing it for over a decade. The appeal is obvious, because most companies run two database worlds, a transactional system for the live application and a separate analytical system for reporting, with a pipeline between them (ETL or change data capture) copying data from one to the other. That pipeline is a standing cost: it adds latency, breaks at inconvenient times, and gives teams one more system to staff and monitor. The dream is to delete it and answer both kinds of requests from one place. What's different now is that the newer tools stop trying to make one engine do both jobs, and instead pair a transactional front end with a separate analytical engine behind it, so each workload runs on the engine built for it.

That single-system approach tends to fit best in a few situations:

• Analytics on operational data that doesn't need a separate warehouse. Dashboards, internal reporting, and lighter analytical queries that used to justify a whole second system can run next to the transactional data they read from.
• Querying data-lake files without moving them. Extensions like pg_lake let Postgres read Parquet and Iceberg tables in object storage directly, so log and event data can be queried in place instead of being ingested first.
• Teams that want fewer moving parts. For a smaller org, one Postgres-shaped system doing both jobs is less to run and reason about than a transactional database plus a warehouse plus the pipeline between them.
• Keeping analytics current instead of a batch behind. Because the analytical side reads from the same system rather than a downstream copy, there's no pipeline lag between a transaction landing and it showing up in a report.
• Teams handling regulated or sensitive data. Every downstream copy of a database is another system to secure, with its own access controls, encryption, and audit trail. For an org managing PII, financial data, or compliance requirements, one system is easier to govern.

The convergence has limits. These systems often write analytical copies of the data to object storage like S3, which is slower than the local NVMe a transactional database runs on, so under heavy concurrent writes a combined system can strain where a dedicated one wouldn't. There's also resource contention: analytical queries and transactional traffic compete for the same CPU and memory. Real warehouse-scale analytics, petabytes or high-concurrency BI across an org, still justifies a purpose-built system, and no extension changes that.

So the question is how much of each workload you have, not whether one system can technically do both. If your analytics are dashboards over operational data, you've probably been running two systems for a job one can now handle. If they're warehouse-scale, the second system is likely still earning its place. Either way, what these tools change is how much analytics work you can handle before you need a second system.

🔍 What We're Watching in the Database Ecosystem

Getting Ready for PostgreSQL 19

Dimitri Fontaine breaks down what's changing in Postgres 19, currently in Beta 3 with GA expected in the coming weeks. He covers the REPACK command, which unifies VACUUM FULL and CLUSTER, with a CONCURRENTLY mode that avoids holding a lock throughout the rewrite. He also covers compatibility breaks and why partition merging/splitting and SQL/PGQ property graph queries were pulled before GA.

The unbearable lightness of one more index

Radim Marek audited 838 indexes across 12 AI-generated PostgreSQL schemas and found the SQL quality mostly solid: only 10 served no clear requirement. The real cost appeared on write-heavy tables. One schema put 16 indexes on a tickets table, six involving a frequently updated column, producing 1.8x the WAL and 1.9x the update time compared with his seven-index baseline. Agents add indexes query by query, without accounting for the write cost.

In Case You Missed It

How We Reached 4.3 Million QPS for MySQL and PostgreSQL workloads on a Single Readyset Node: Our latest release pushes single-node throughput to 4,379,212 cached queries per second at 2.26 ms p95, 6.4x the previous release on the same hardware, by working down the serving path one bottleneck at a time (starting with spreading connections across multiple async runtimes). The write-up walks through exactly what changed and where the CPU goes now.

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.