Adding a database engine as data, not code

Ask most internal database platforms to support a new engine and the answer is a development ticket: someone writes an integration, tests it, and ships a new platform release. That is the quiet reason self-service database platforms stall, every new engine is a code change. There is a different way to build one, where adding an engine is a data change, not a code change.

The Kubernetes operator did the hard part already

On Kubernetes, the community has already written the difficult, engine-specific automation as operators: CloudNativePG for PostgreSQL, the Strimzi operator for Kafka, Percona’s operators for MySQL and MongoDB, and so on. Each one knows how to provision, fail over, back up, and upgrade its engine. A platform does not need to re-implement that; it needs to discover which operators are installed and offer them.

Discovery by custom resource, not by hard-coding

An operator announces itself by installing custom resource definitions into the cluster. A background scanner can watch for exactly those definitions and, when it finds a new one, publish the engine into an admin catalog as something that can be enabled, priced, and offered. The list of supported engines becomes a property of what is installed in the cluster, discovered continuously, rather than a constant compiled into the platform.

Why “engine as data” matters operationally

For an engine with an existing supported adapter, catalog configuration can make it available without a platform release. That still calls for validation of the operator version, lifecycle actions, and backup path. A previously unsupported engine may need adapter code and integration tests before discovery can turn it into a usable service.

How Nothi does it

Nothi discovers installed database operators by the presence of their custom resource definitions and publishes each into an admin-curated catalog, so an already supported engine can become offerable through catalog configuration. Discovery does not create support for an arbitrary new operator. That catalog-driven model is how it supports twelve engines today, from PostgreSQL and MySQL to Kafka, MongoDB, and a vector database, from one control plane, with room to add more without a redeploy.