EnterpriseDB (EDB) and Altinity are consolidating their efforts to bridge Postgres and ClickHouse, reducing the engineering overhead that developers face when maintaining both systems in parallel.

Applications requiring both reliable transactional storage and rapid analytical queries encounter a fundamental architectural tension. Postgres serves as the system of record—holding orders, accounts, and critical state that applications depend on. ClickHouse handles the analytical workload: processing billions of events, identifying cohort behavior, and generating insights at scale. Each engine excels within its domain, yet the integration between them creates operational friction.

Both engines are excellent at their jobs. The misery lives entirely in the gap between them.

EDB has acquired Altinity, the company behind Altinity Stable Builds, the Altinity Kubernetes Operator, and Altinity.Cloud. The strategic significance extends beyond corporate structure: the top contributor to Postgres now shares a roadmap with engineers who have operated ClickHouse in production for nearly a decade, targeting three recurring operational challenges.

Pain 1: Change Data Capture becomes your product

Moving data from a committed Postgres transaction to a queryable row in ClickHouse requires orchestrating multiple components: replication slots, connectors with their own failure modes, message brokers that must be sized and secured, sink connectors that handle schema evolution without silently dropping columns, and deduplication logic to manage at-least-once delivery semantics.

Monitoring each hop becomes mandatory—lag at any stage transforms a "real-time" dashboard into stale information. None of this integration code represents your core product, yet the entire pipeline lands on the on-call rotation, triggering pages at inconvenient hours.

Pain 2: Agents operating on stale aggregates

Agentic workloads have shifted the cost of data staleness. A dashboard lagging by 20 minutes causes frustration. An autonomous agent approving refunds, repricing inventory, or flagging transactions based on 20-minute-old aggregates produces incorrect decisions at machine speed, potentially affecting thousands of transactions before detection.

An agent that approves a refund, reprices inventory, or flags a transaction on a 20-minute-old aggregate is wrong, and wrong at machine speed, thousands of times before anyone notices.

Developers building agents resort to manual coordination: querying Postgres for current state, querying ClickHouse for trends, stitching results in application code, and hoping clock synchronization holds. The application layer becomes the integration layer, and integration layers harbor bugs.

Pain 3: Operating duplicate governance across two stacks

Row-level access rules, column masking, and policies like "analysts see aggregates, not customer IDs" must be implemented in both Postgres and ClickHouse. These implementations drift when updates occur in one system and are forgotten in the other. Running ClickHouse on Kubernetes demands specialized expertise: Keeper configuration, storage class selection, replica placement, backup strategies, upgrades, and typically one or two engineers who become the de facto ClickHouse specialists.

Organizations choosing managed analytics services face a different constraint: data residency determined by vendor infrastructure and billing models tied to vendor pricing, not internal infrastructure costs. Two engines require two permission models, two operators, two support contracts, and vendor lock-in that was never explicitly chosen.

Pillar 1: Shared layer replacing pipelines

Currently, Postgres, WarehousePG (EDB's MPP warehouse), and ClickHouse can all read Apache Iceberg tables and query each other. Postgres writes the authoritative record while ClickHouse reads through the same open table format, reducing data movement and integration complexity. The planned evolution involves a unified shared catalog and governance model spanning all three engines, plus a single control plane for Postgres and ClickHouse.

The architecture roadmap positions Iceberg as today's shared layer, with EDB's control plane as the future operational foundation. The shared catalog represents the design target rather than current functionality. The objective mirrors what teams would architect themselves: minimal hops, unified catalog, elimination of custom reconciliation code. The Change Data Capture pipeline transitions from a team responsibility to an implementation detail.

Pillar 2: Current data for agents with enforced governance

EDB Postgres AI combines a sovereign multi-model data layer with agentic runtime capabilities and governance enforced at the Postgres data layer—at the point of action with audit trails. For agents, the goal becomes requesting business context and receiving both the record and analysis from a single system, rather than application code orchestrating two databases and a queue.

On the permissions side, unified governance across all three engines is part of the roadmap. Postgres currently enforces purpose-bound access for agents while ClickHouse applies its own role-based access control. The plan calls for defining policy once at the data source and having every engine enforce it, eliminating re-implementation in application code or secondary permission layers. Agents can reason over current data without security reviews blocking releases.

Pillar 3: Unified operations and deployment flexibility

Altinity's production approach to ClickHouse centers on the Kubernetes Operator, which has exceeded 100 million pulls, with Altinity Stable Builds maintained for three years including security and bug-fix backports. This operational expertise now resides within the top Postgres contributor, which also created CloudNativePG and donated it to the open source community, where it operates as a CNCF project and the Postgres operator many organizations already deploy. One vendor now understands both operators.

The roadmap includes a unified control plane running Postgres and ClickHouse, with a single support organization responsible when the two interact poorly. Deployment location remains a customer choice: bring-your-own-cloud, self-hosted Kubernetes or OpenShift, air-gapped environments, or fully managed services. Altinity.Cloud already deploys into customer cloud accounts, and EDB Postgres AI runs in customer accounts or on-premises. When regulatory requirements, financial constraints, or latency budgets dictate data residency, the stack adapts to the constraint rather than forcing the constraint onto the stack.

The unified approach

Three operational challenges map to three architectural pillars, leading to a single principle: the application layer should cease being the reconciliation point between two databases. Postgres maintains the authoritative record. ClickHouse answers analytical questions on the same live data. Every component removed from the middle represents code teams no longer debug, monitor, or justify to auditors.

The best pipeline is the one you never have to write.

For development teams that have spent years manually synchronizing two databases and explaining inconsistencies to auditors, product managers, and stakeholders, this promise warrants attention. Testing each planned component as it ships will reveal whether the unified approach delivers on its premise.

The software and services described in this announcement are provided by EDB and Altinity, not ClickHouse, Inc. This announcement does not imply sponsorship or endorsement by ClickHouse, Inc. Altinity is an independent company and is not affiliated with ClickHouse, Inc. ClickHouse is a registered trademark of ClickHouse, Inc.