Imagine you are building a massive Lego castle, but instead of finding every brick yourself, you have a smart robot helper that organizes everything for you. In the world of computers, Kubernetes is like that Lego set, and Open Everest is the smart helper for managing databases. Today, we are going to explore how Open Everest is transitioning into a fully independent project and why this is such a big deal for developers and the open-source community.
To understand Open Everest, we first need to look at the problem it solves. Sergey Brunin, a key figure in this project, explains that running databases on Kubernetes can be quite difficult. In the past, developers used tools called “Operators” which acted like automated scripts to handle tasks like backups or scaling. However, using these operators still required a lot of manual configuration and knowledge of complex code files called manifests. Open Everest was created to simplify this even further. It acts as a platform that sits on top of these operators, giving users a simple way to deploy and manage databases without getting lost in the complicated details of Kubernetes administration.
A major shift is happening right now as the project transitions from “Percona Everest” to just “Open Everest.” This change is not just about the name; it is about governance and community. The team is donating the project to the CNCF, which stands for the Cloud Native Computing Foundation. This is very important because it means the project will be “vendor-neutral.” Instead of being controlled by one single company, it will be owned by the community. This ensures that no single company can suddenly change the license or take the project away from the users. It builds trust because everyone knows the project is there to stay and will be managed fairly through voting and open discussions.
Let’s talk about the technology inside Open Everest. The team is working on a new “Extensibility Framework.” This is a fancy way of saying they are making it super easy to add new types of databases to the platform. Previously, adding a new database technology took a lot of work and expertise. Now, they are building a system where a developer can use a simple Software Development Kit (SDK) written in the Go programming language. You write some code to describe how your database works, such as how it handles nodes and replicas, and the system automatically generates the necessary “Operator” and “Helm Chart” for you.
To visualize how this works, Sergey described a process where you also define what the user interface (UI) looks like using a YAML file. This is very clever because it allows developers to create buttons and checkboxes for specific features, like enabling “sharding” in MongoDB or adding extensions in PostgreSQL, without writing complex frontend code. You simply describe the fields you want, and Open Everest renders them on the screen.
apiVersion: everest.io/v1alpha1
kind: DatabaseCluster
metadata:
name: my-postgres-db
spec:
engine:
type: postgresql
replicas: 3
storage:
size: 10Gi
# This is where the UI definition helps users select options
uiConfig:
showExtensions: true
enableSharding: false
The ecosystem around Open Everest is also growing rapidly. While Percona remains an expert in the database engines themselves, a new company called Solanica has been formed to focus specifically on the success of the Open Everest platform. Solanica will work on commercial success and support, but the core project remains open source. This separation is good because it clarifies who to talk to. If you need help with the database internals, you talk to database experts like Percona. If you need help with the platform features or want to build a custom plugin, you might look toward Solanica or the broader community.
Looking at the roadmap, the community is asking for support for more than just standard databases. There is a high demand for technologies like Redis, ClickHouse for analytics, and even vector databases which are essential for Artificial Intelligence (AI) projects. Additionally, with recent changes in the licensing of other tools like MinIO, there is a push to add object storage solutions to Open Everest. This transforms the project from just a “Database as a Service” into a complete platform for all kinds of data workloads on Kubernetes.
As we wrap up this lesson, it is clear that Open Everest represents a mature step forward in the cloud-native world. By moving to an open governance model under the CNCF, the project invites students, developers, and companies to contribute without fear of vendor lock-in. If you are interested in learning more, the best action you can take is to visit their GitHub repository or join their Slack channel. You do not need to be an expert to help; simply fixing documentation or testing the installation are great ways to start your open-source journey.