In my experience, many proponents of “Postgres for everything” haven’t been exposed enough to (newer) purpose-built technologies and the tremendous value they can create. I was firmly in that camp for nearly a decade while working at Citus and on the Microsoft Postgres team. After building PeerDB (a Postgres CDC product that syncs data to various systems) and working at ClickHouse, my perspective completely changed. Seeing firsthand the “magic” that purpose-built systems deliver for their specific use cases—especially in terms of cost, performance, and scale—was truly eye-opening.

Don’t get me wrong—I’m a huge Postgres proponent and have spent 10 years helping customers implement it. However, I strongly believe in using Postgres for what it was designed for in the first place. Postgres is a row-based OLTP database, with over 30 years of engineering effort dedicated to making it robust for that specific workload.

Proponents of “Postgres for everything” often argue that a single stack is simpler and reduces complexity. What’s frequently overlooked, however, is the CAPEX and OPEX required to make Postgres work well for use cases it wasn’t designed for. At Citus, many customers had reasonably sized teams of Postgres experts whose primary job was to constantly tune, operate, and “babysit” the system to keep it working at scale.

Separately, we’re seeing the need for purpose-built technologies emerge much earlier in a company’s lifecycle, likely driven by AI. At ClickHouse, many customers using Postgres CDC are seed-stage companies that have grown rapidly. We pulled together some data that highlights these trends here: https://clickhouse.com/blog/postgres-cdc-year-in-review-2025#use-cases

Ultimately, I believe it’s better to make it seamless and even magical for users to integrate purpose-built technologies with Postgres, rather than making an overgeneralized claim of “Postgres for everything.”