Postgres Bridge Between Apps and Analytics
Charles Chretien, co-founder of Prequel, on the modern data stack’s ROI problem
This was a land grab for the developer starting point, not just a product extension. Snowflake and Databricks already owned the place where data teams analyze data, but application databases sit earlier in the workflow, where a developer first creates the app, writes transactions, and stores live user data. Buying into Postgres let them move upstream, capture workloads before they ever become warehouse spend, and offer a more complete stack as customers consolidate around fewer vendors and more standard formats.
-
Databricks had a natural path from managed Spark into warehousing and ML, but still needed an OLTP layer. Neon gave it a serverless Postgres built for fast database creation, branching, and agentic workflows, which matters when AI apps spin up many short lived databases.
-
Snowflake started with the warehouse, which is further downstream. Crunchy Data gave it enterprise Postgres operations, especially for Kubernetes and regulated production use cases, plus technology for connecting Postgres with Iceberg style analytics workflows.
-
This does not mean database fragmentation is getting worse in the old sense. More products are appearing, but many are converging on shared standards, with Postgres on the transactional side and open table formats like Iceberg and Delta on the analytical side.
The next step is a tighter merge between app databases and analytics platforms. The winning vendors will let a team start with Postgres for the product, then add pipelines, analytics, AI, and observability without moving to a different core system. That pushes the market toward fewer control planes, even as specialized engines keep appearing underneath.