Back to blog

Change the database: Two engineering teams on open source, hard forks, and sovereign data

November 04, 2026

Based on a conversation with Altinity's Robert Hodges and Max Romanenko, CTO at EDB

Some engineering principles survive every product cycle. When Robert Hodges of Altinity and Max Romanenko of EDB compared how their teams build, they kept returning to one: the code stays open, and the people running it must be able to change it. What follows is the engineering behind that idea.


Open source as an operating model

EDB’s version starts with a short list: no corporate ownership, radical permissiveness and stability in licensing, and open, quality-first engineering culture. The commercial logic follows. Customers get top-notch support from the people who are actively contributing to the project, which means freedom from vendor lock-in and zero licensing audits.
 

Altinity arrived at the same place through ClickHouse® software. The database was fast, but many databases are. What mattered was that it was open source and built by an enormous community of people. Altinity engineers have since contributed close to 900 pull requests, built a Kubernetes operator for ClickHouse clusters, and released open source tooling that runs from Grafana to replication. Openness doubles as a trust mechanism. Because people can see how the technology works, Hodges says, “we’re not going to pull the rug out from under them.”


You have to be able to change the database

Production experience sharpens the point. “In order to build these systems, you need to be able to change the database,” Hodges explains. “That’s the whole heart of open source.” Customers rarely write database internals, and they do not need to. “Our customers aren’t necessarily all C or C++ programmers. But what they do bring to the table … they have a problem.” Altinity’s job is to connect that problem with the C++ developers who can solve it inside ClickHouse software.


EDB’s experience matches. Its changes “were rooted in the real customer problems that we were solving for them,” Romanenko notes, and Hodges adds the corollary: “The further you stray away from that ideal of solving customer problems, the less likely, in many cases, it is that you’ll be successful.”


The price of a hard fork

WarehousePG shows what stewardship costs. It is a massively parallel processing, Postgres®-based data warehouse forked from Greenplum®, which stayed open source for almost ten years only to be relicensed when Broadcom acquired VMware in 2023. EDB forked the last open source version so customers could avoid the new licensing fees.


The fork carries technical debt. WarehousePG sits on a Postgres 12 kernel while the current release is 18, seven major versions ahead. That means patching out of band, backporting Postgres extensions. Other forks tried to move the kernel forward, but most failed in the quality department. When VMware maintained Greenplum, its one kernel upgrade took over a year, "and it was very, very painful.”


EDB’s WarehousePG team took the climb anyway: “4,500 merge conflicts over 7 releases that require a lot of depth, a lot of breadth, and a lot of discipline.” It is the kind of work Romanenko compares to Altinity’s Project Antalya, a technically deep problem worth taking on because it serves both customers and the community.


One continuum, three engines

At the engine level, Romanenko sees a natural operational to analytical continuum. The roles divide cleanly: “Postgres preserves transactional states. ClickHouse analyzes massive volumes of real-time data. And WarehousePG serves as a long-term historical analytics platform.” Open data formats such as Apache Iceberg add a fourth pattern, the lakehouse, which both teams are working to support.


The customer problem that links them is “the Postgres analytics cliff,” followed by “the operational friction of dual or even triple system architecture.” Teams often have deep relational skills and little distributed OLAP experience, or the reverse. The blueprint both teams describe is to design the operational schema in Postgres so it can stream cleanly into ClickHouse without destabilizing the primary database, then serve sub-second analytics on top. The engines are not integrated today, and the teams frame this as the direction they are building toward.


Why agents favor shared, open data

Agents raise the stakes. Hodges argues that AI is going to drive consolidation into shared pools of data on open source, because silos are hard for AI agents to use. The principle: “You just need access to data, and you need to go straight to the source.” For agentic workloads, Romanenko adds, that means sub-second access to transactional data extracted from Postgres into ClickHouse software. Hodges notes that AI systems learn on open source databases, so Postgres, ClickHouse, Iceberg, and WarehousePG are what they know best.


Sovereignty you can inspect

Sovereignty, in Romanenko’s definition, is control over data: “where it lives, who controls it, who has the off switch.” Hodges sees the same idea under a different name: “You call it sovereign data, we call it BYOC, but we’re both talking about the same thing.” EDB Postgres AI runs in the cloud, in bring-your-own-cloud deployments, as a managed service, on premises, and in hybrid environments. 

Because the core is Postgres, the claim can be tested. “It’s not enough to just say, yes, of course, you have the full control,” Romanenko points out. It has to be verifiable. “You can see the code, and it’s portable, you can move your workloads.”


The next wave

Hodges places all of this in the history of databases, which advances in waves. “We never abandon things in computer science. We just build new things beside them.” Cloud databases and shared object storage defined the current wave. The next, he suggests, is "a model that is as comprehensive and as capable as Snowflake®, but to do it on sovereign data," with a management model that runs in the customer’s environment, from hyperscalers to neoclouds to devices running on factory floors.


None of this is a product announcement or roadmap. It is a candid look at how two teams think. As Hodges puts it, “It takes a decade to do anything really important.” And for Romanenko, the common thread is plain: “We all like taking on hard problems to deliver value to our customers.”


Keep going. Read the announcement and hear Robert Hodges on AI & Data Horizons. Questions about Postgres and ClickHouse software in your environment? Contact us. 


ClickHouse is a registered trademark of ClickHouse, Inc., and EDB is not affiliated with, associated with, or sponsored by ClickHouse, Inc. https://clickhouse.com/

Greenplum is a registered trademark of Broadcom Inc. EDB and EDB Postgres AI are not affiliated with, endorsed by, or sponsored by Broadcom Inc. Any references to Greenplum are for comparative, educational, and interoperability purposes only.

 

Snowflake is a registered trademark of Snowflake Inc.

Share this