Postgres Compatibility as Adoption Tactic

Postgres support is a distribution tactic, not a real merge of transactional and analytical databases. The point is to make an OLAP engine feel familiar enough that a team already running Postgres will try it, instead of asking that team to replace its core app database on day one. In practice, the hard parts still remain, keeping two systems in sync, handling updates cleanly, and avoiding a brittle CDC pipeline.

• The interview makes the underlying workflow concrete. Teams often start with Postgres for the app, add ClickHouse for fast analytics, then run into duplicated data, sync overhead, and query complexity across two systems. That is why Postgres compatibility helps with adoption, but does not remove the two database problem.
  1 sacra
• This has become a broader market pattern. Databricks bought Neon in May 2025 to add serverless Postgres, and Snowflake announced its Crunchy Data acquisition in June 2025 to bring Postgres into its stack. That points to a land grab for developer entry points, not a settled technical answer to OLTP plus OLAP in one engine.
  3 sacra 4 techtarget 5 businesswire
• A useful comparison is MotherDuck's pg_duckdb extension, which lets a Postgres deployment run analytical queries without exporting data to a separate cloud service. That is closer to solving a user workflow directly, because it meets teams inside the database they already use rather than asking them to wire together another system.
  6 sacra

The next phase of competition is likely to center on who can turn Postgres adjacency into a true product wedge. The winners will be the vendors that move from simple compatibility to a setup where developers can write application data, run analytics, and avoid constant data movement, all without learning two different operational models.