Since the early days, OpenEverest has been the database-as-a-service that runs anywhere. We called it a platform because it supports multiple database technologies. But a true platform is something extensible — something where new features can be added easily without modifying the core.
With a monolithic core, OpenEverest could hardly be called a platform, as adding new features or integrations was difficult and time-consuming.
That is why we believe v2 is a big deal — OpenEverest's architecture is now modular. In this blog post, we look into this new structure and how these changes will shape the future of the project. Also read the project's official blog post about the release.
Note: OpenEverest v2 is still in Developer Preview. Do not use it in production.
The "More Databases" Problem
When we were building Percona Everest (before it became OpenEverest), we wanted to move fast. The fastest way is not always the best one, but we needed to get from A to B as soon as possible.
The goal was to simplify deployment and management of databases on Kubernetes through a single control plane - Web UI, API, and Custom Resource Definitions. Instead of scattered solutions and various Kubernetes Operators, users now had a single go-to solution. That worked well in the short run, but created a problem: adding new database technologies or maintaining existing ones was hard and time-consuming.
Someone who wanted to add a new database or storage technology into OpenEverest would face a steep learning curve: understand how Kubernetes primitives work, learn the Operator Framework, navigate the Go code of the everest-operator, and then work through the React/JavaScript code to reflect changes in the UI. And then came the pain of upgrading and maintaining that operator - every new feature or version required code changes and a full release of OpenEverest.
Introducing Providers
Providers are all about adding new data, database, storage, or AI technologies into the stack. Using the Provider SDK, developers can integrate their own operators into OpenEverest without heavy engineering effort. With a YAML manifest, they can describe the Web UI flows flexibly.
What's interesting about Providers is the architectural change in the core of OpenEverest. We removed the version-service and Operator Lifecycle Manager (OLM). Providers are now plugins that live outside the core. This enables full decoupling — upgrading an Operator to add new capabilities no longer requires a release of OpenEverest itself.
Here is the "before" and "after" look at the architecture:
Not only can you now add more value to OpenEverest, but you can do it fast. A Percona engineer (oksana-grishchenko) - someone not deeply involved in v2's core development - created a working proof-of-concept plugin for MySQL based on Percona XtraDB Cluster in just a few days. Or another good example - Javier Zon from Scale DB created a Provider for ClickHouse based on Altinity Operator. The complexity that previously required months of coordination now happens within a self-contained plugin.
The Integration and Value Problem
Another set of problems that OpenEverest users stumbled upon: integrations with the cloud-native ecosystem and minor enhancements to the platform. What if you need to query a database from the UI? Or you want to add a new proxy in front of your database cluster that is not currently supported by the Operator? Or add an AI copilot that automatically has database credentials and access to Kubernetes clusters?
Generic Plugins
There are many use cases, and it is hard to implement them all in the core. That is where Generic Plugins come in.
They allow teams to extend the OpenEverest UI and API with custom functionality. These aren't just cosmetic additions — they're full-stack extensions that can interact with your infrastructure.
What Early Dev Preview Means
OpenEverest v2 is currently in Developer Preview — an early look at what's coming. This isn't production-ready software yet, but it signals the direction. The architecture is solid, the SDK is available, and early adopters can start experimenting with plugin development.
Breaking changes are expected as the platform moves toward General Availability. But for teams evaluating their database strategy, now is the time to understand how this modular approach aligns with your long-term infrastructure goals.
The Bottom Line
OpenEverest v2 transforms database orchestration from a vendor-controlled roadmap into an extensible platform that adapts to your needs. Whether it's adding support for a new database technology through Provider Plugins or building custom operational tools via Generic Plugins, control shifts to the teams using the platform.
For organizations managing complex data infrastructure, that's a very big deal indeed.
---
Ready to explore? The Provider SDK and Generic Plugin template are available now. Check out the OpenEverest documentation to get started, or read the full v2 Developer Preview announcement on the project blog.