Evolving the ORM for the Analytical Database

To some developers, ORMs are an indispensable productivity tool; to others, they are a leaky abstraction to be avoided. But their fundamental goal is to solve the persistent challenge of bridging the chasm between application code and relational databases. In the world of transactional (OLTP) apps, they offer a path to faster development, even if the trade-offs are hotly debated. But when you turn to the world of analytical (OLAP) databases like ClickHouse, the model breaks down entirely. The foundational assumptions of an OLAP engine—columnar storage, bulk operations, eventual consistency—are simply incompatible with traditional ORM design.

This mismatch means the abstraction is no longer just leaky; it's fundamentally misaligned. But the developer's need for a better interface to the database remains. So, what if we learned from the ORM playbook without repeating its mistakes? In a post we co-authored with ClickHouse, we explore how to build a more appropriate abstraction for analytics—one designed for the unique architecture of OLAP and focused on making developers more productive.

We believe there is a better way, a new generation of ORMs that are built from the ground up for the world of analytical databases, rather than trying to adapt existing tools that were designed for a different paradigm.

You can read the full argument on the ClickHouse blog Does OLAP Need an ORM?