Klio Brings Continuous WAL Streaming and Near-Zero Data Loss to CloudNativePG

What EDB Announced in Salt Lake City

EnterpriseDB (EDB) used KubeCon + CloudNativeCon North America 2026 in Salt Lake City to donate Klio, its backup and recovery tool for Postgres on Kubernetes, to the CloudNativePG (CNPG) community. The company also previewed two enterprise offerings built on the operator. The timing matters. CNCF accepted CNPG as an Incubating project on Nov. 10, and EDB finished its acquisition of Altinity, the creator of the Altinity Kubernetes Operator for ClickHouse, less than a week earlier.

Here's the thing: donating a tool to an open source project is rarely a neutral act. It signals that a vendor wants its work to become a shared standard rather than a product sold on top of someone else's. This is more significant than it looks, because backup tooling is the kind of component teams rarely swap out once it's wired into their runbooks. If you're evaluating Postgres on Kubernetes, the question isn't only what the tool does today. It's who steers its direction once the code belongs to a community.

Closing the Five-Minute Gap

CNPG's built-in backup options archive the Postgres write-ahead log (WAL) only as completed segments. That means an outage can wipe out up to five minutes of transactions. Log shipping is a common pattern in database operations, and most operators can recite its trade-offs from memory. A five-minute window is tolerable for some workloads and painful for others, especially where a lost transaction has direct customer or financial consequences.

Klio takes a different approach. It streams WAL continuously and keeps a local copy alongside the cluster, so restores run at disk speed instead of pulling a full copy back from remote storage. (And this is the part most people overlook) recovery time matters as much as recovery point. A restore that has to drag everything back across the network stretches every incident, and the people on call feel that stretch first.

Local copies are a trade-off, not a free lunch. They speed up restores but add storage to manage on every node, and you still need a remote copy for disasters where the cluster itself is gone. Klio's design sits between those two needs. That's why it's worth reading the architecture closely before assuming it fits your setup.

Enterprise Features Without Swapping Operators

Security is built in rather than bolted on. Klio encrypts data in transit and at rest using rotatable keys that customers control. It supports local volumes, S3-compatible object storage, or both. One Klio server can protect many clusters and shows the health of every backup from a single view, which is the part platform teams will likely care about once they're past the proof-of-concept stage.

Customer-held, rotatable keys are table stakes for many regulated environments. The announcement doesn't spell out how key management works in practice, though, so the details will matter more than the headline. Single-pane visibility sounds mundane. Yet it's usually where backup programs fail quietly, because a backup nobody checks is a backup in name only.

EDB is previewing two paths. The first is an EDB distribution of Klio with certified images, enterprise support, and long-term-support releases. Long-term-support matters most to teams that can't upgrade every few months, which describes a lot of large enterprise shops. The second is the EDB Postgres AI Plugin for CloudNativePG, which adds enterprise features such as transparent data encryption to open source CNPG. That plugin works without replacing the operator, so teams already running CNPG don't have to re-platform to get it.

Both are slated for general availability by the end of 2026. Community images remain free. That split is the business model in one line, and it's a familiar one. The open image gives adopters a reason to start, while the paid layer covers certification, support contracts, and the features that matter once a database holds sensitive data.

EDB framed the announcement in broader terms. "By continuing to invest and give back across the open source communities behind Postgres, ClickHouse software, and the cloud-native ecosystem, we give enterprises the foundation to build that future at scale, on infrastructure they own and control," said Max Romanenko, CTO of EDB. Read that as the pitch it is: a promise to keep funding open communities while selling the parts enterprises want to own outright.

Postgres and ClickHouse on One Control Plane

With Altinity now part of EDB, the company wants both operators to function as one multi-model data layer, which it calls EDB Postgres AI, running natively on Kubernetes. The idea rests on a shared declarative operator pattern. Teams could run transactional Postgres alongside ClickHouse analytics fed by change data capture, all under one operating model.

That said, the convergence story is still mostly a roadmap. Operators for analytics databases have their own maturity curve, and ClickHouse has different scaling and storage habits than Postgres. Putting both under one control plane doesn't erase those differences. It just puts them in the same YAML. EDB plans to introduce integrated enterprise ClickHouse capabilities in the fourth quarter of 2026, so the real test will come when those features ship.

My read: if the operators share the same lifecycle and backup model, Kubernetes platform teams get one set of runbooks instead of two, and that's where the practical value sits. If they don't, you've got two operators with a shared logo. That's a smaller win, and you should price it that way.

What This Means for Platform Teams

If you're running CNPG today, the Klio donation is worth a close look regardless of whether you ever buy an EDB product. The open tooling gives you a clearer path to continuous WAL streaming than the built-in options, and the community ownership reduces the risk of building on a tool that could change direction overnight. Read the project's governance and contribution docs before you commit, though. Community ownership only means something if the contributor base actually grows.

The bigger question is whether enterprises will accept a model where the operator is free and the enterprise layer is a plugin on top. That model works well when the open project is healthy and the paid features are clearly separated. It gets messy when users can't tell which parts of their stack they're paying for. Watch how the certified images and the plugin are priced and packaged when they reach general availability. That's where the real intent shows up.

And yet the most interesting part may be the least finished. A single operator model across Postgres and ClickHouse would be a meaningful step for teams that currently juggle separate tooling for transactional and analytical data. Whether it becomes that depends on the fourth-quarter releases and on whether EDB keeps the two projects independent enough to earn community trust. Until those features ship, treat the convergence story as a promise to test, not a platform to bet on.