Skip to content

[Sandbox] OpenEverest #450

@spron-in

Description

@spron-in

Project summary

Cloud Native database platform

Project description

OpenEverest is an open source platform for running, managing and scaling data workloads on Kubernetes. Through modular structure it allows community to not only choose workloads, but also have various flexible integrations with tools they love.

Org repo URL (provide if all repos under the org are in scope of the application)

https://github.com/openeverest/

Project repo URL in scope of application

https://github.com/openeverest/openeverest

Additional repos in scope of the application

https://github.com/openeverest/everest-doc
https://github.com/openeverest/openeverest-operator
https://github.com/openeverest/openeverest-catalog
https://github.com/openeverest/openeverest.github.io
https://github.com/openeverest/roadmap
https://github.com/openeverest/vision

Website URL

https://openeverest.io

Roadmap

https://github.com/openeverest/roadmap

Roadmap context

We also created a vision for the project to highlight its overall direction: vision.openeverest.io

Contributing guide

https://github.com/openeverest/openeverest/blob/main/CONTRIBUTING.md

Code of Conduct (CoC)

https://github.com/openeverest/governance/blob/main/CODE_OF_CONDUCT.md

Adopters

https://github.com/openeverest/openeverest/blob/main/ADOPTERS.md

Maintainers file

https://github.com/openeverest/governance/blob/main/MAINTAINERS.md

Security policy file

https://github.com/openeverest/openeverest/blob/main/SECURITY.md

Standard or specification?

We capture specs in specs repository

Business product or service to project separation

There are services provided by Percona for OpenEverest (originally the project was Percona Everest).
There is a platform for users standardizing on OpenEverest - Solanica Platform

The goal for OpenEverest is to be trully vendor neutral and be the upstream.

Why CNCF?

Submitting OpenEverest to the CNCF is necessary to establish a unified, extensible data platform for managing databases natively on Kubernetes. This move immediately connects OpenEverest with the cloud-native ecosystem, accelerating the development of its modular architecture and ensuring support for multiple database engines and plugins via community contributions. The CNCF's governance ensures the project is built using rigorous best practices, meeting critical user requirements for stability, security, and integration within the Kubernetes environment. We specifically chose the CNCF for its neutral, vendor-agnostic foundation, which provides the trust and longevity required for a truly foundational piece of data infrastructure. This collaboration confirms our commitment to open development and positions OpenEverest as the standard solution for stateful workloads in the ecosystem.

Benefit to the landscape

The primary benefit OpenEverest brings to the Cloud Native Landscape is solving the current, fragmented state of running stateful workloads. Today, users must adopt a patchwork of different database Operators—one for PostgreSQL, another for MySQL, and so on—each with unique APIs and operational models, which creates significant complexity and a steep learning curve. OpenEverest provides the missing unified, extensible platform layer that standardizes the management and user experience across all database engines and data workload types. This common, modular architecture is the key differentiator, drastically lowering the operational burden for platform teams and accelerating the adoption of diverse data services within Kubernetes without vendor or operator lock-in. Ultimately, OpenEverest will serve as the essential, community-governed foundation for data within the CNCF, mirroring Kubernetes' role for compute.

Cloud native 'fit'

OpenEverest fits within the Database subcategory under App Definition and Development. It embodies cloud-native principles by using Kubernetes Operators and declarative APIs to provide a standardized, automated, and modular platform for managing diverse stateful workloads.

Cloud native 'integration'

Kubernetes, Operators SDK, potentially other CNCF projects in data space: CloudNative PG, Vitess, Strimzi, etc.

We will add other data operators as plugins to ensure users have a choice. We are open to add not only databases, but other tools to support data workloads and tasks (like object store, analytics, etc).

Cloud native overlap

The project will overlap with standalone database-specific projects once they are added as plugins into OpenEverest.

CloudNativePG, Strimzi, Vitess, and others.

Similar projects

KubeDB - not open source
KubeBlocks

Landscape

Link to landscape

Trademark and accounts

  • If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

IP policy

  • If the project is accepted, I agree the project will follow the CNCF IP Policy

Will the project require a license exception?

N/A

Project "Domain Technical Review"

In progress

Application contact email(s)

sp@solanica.io

Contributing or sponsoring entity signatory information

If an organization:

Name Address Type (e.g., Delaware corporation) Signatory name and title Email address
Solanica 160 Mine Lake Ct Ste 200 Raleigh, NC 27615 Solanica Inc (North Carolina Incorporation) Sergey Pronin, Founder sp@solanica.io
Solanica 160 Mine Lake Ct Ste 200 Raleigh, NC 27615 Solanica Inc (North Carolina Incorporation) Peter Farkas, CEO peter.farkas@solanica.io

CNCF contacts

Jorge Castro

Additional information

No response

Metadata

Metadata

Assignees

Type

No type

Projects

Status

🤔 In voting

Status

New - Sandbox Pending Review

Relationships

None yet

Development

No branches or pull requests

Issue actions