Nothi
Nothi turns a request for a managed database into a running, backed-up, metered instance inside an isolated Kubernetes tenant, across many engines, from one catalog-driven control plane. Engine availability is data-driven, so new engines are added by enabling them, not by shipping platform code.
Nothi is a Kubernetes-native managed database platform. It turns a request for a database into a running, backed-up, metered instance inside an isolated Kubernetes tenant — across twelve engines, from one catalog-driven control plane — on infrastructure you control.


What Nothi does
A background scanner discovers installed database operators by the presence of their custom-resource definitions and publishes each one into an admin-curated catalog, so a new engine becomes offerable by enabling and pricing it as data rather than by shipping platform code or redeploying.
Every engine is driven through a single operator-agnostic lifecycle surface — create, resize, restart, version-upgrade, scale out, back up, and restore — so the same self-service actions and reconciler-owned day-2 operations present one uniform surface regardless of which engine sits behind them.
The default Silo tier gives each organization its own Kubernetes namespace with a network policy that blocks cross-tenant connections, a resource quota, and limit ranges, so one tenant can never open a connection into another tenant's database.
An opt-in Pool tier packs many small tenants onto one shared CloudNativePG cluster as isolated logical databases, each with a dedicated owner and login role and public access revoked, trading the namespace boundary for lower cost and faster provisioning while keeping a hard per-tenant boundary.
Each engine backs up through its own purpose-built path — Barman for PostgreSQL, Percona XtraBackup for MySQL, Percona Backup for MongoDB, native snapshot APIs for OpenSearch and Qdrant, Oracle Data Pump, and job-based exports for Valkey, Kafka, and RabbitMQ — into a dedicated object store, giving every enabled engine a validated backup-and-restore path.
A destructive delete is gated behind a verified final backup and an emailed one-time confirmation code and fails closed, so any backup failure or timeout preserves the data instead of wiping it unless an explicit consent bypass is used.
The only route for a platform operator to reach a tenant database is a per-incident, instance-scoped, time-boxed session requiring customer approval (or a flagged break-glass), a fresh step-up authentication code, curated read-only introspection and named emergency actions instead of raw SQL, and full recording to a customer-visible transparency log — and it ships switched off by default.
Database credentials and logs are carved out of the platform super-admin's authority and held only by an organization's own owners and admins, so no platform operator holds standing cross-tenant access to a tenant's plaintext secrets or query text.
Password verification alone returns only a short-lived challenge; a session is issued only after a time-based one-time-code step, with the secret encrypted at rest under a dedicated key and single-use, attempt-capped challenges, so a stolen password cannot by itself obtain access.
Each organization can bring its own identity provider over authorization-code-with-PKCE and asymmetric-only token verification, with the landing organization bound from server-side state rather than the identity token, adding enterprise single sign-on without weakening the cross-tenant boundary and activating per organization once an identity provider is configured.
Hourly metering feeds an integer-cents credit ledger priced across four admin-set dimensions — engine, compute size, HA replica factor, and provisioned storage — with suspend-at-zero for prepaid and dunning with overdue-suspend for postpaid, all configured as data that defaults to no change on deploy.
Every mutation writes to an immutable audit log that survives even organization deletion, and each release image carries an SBOM, SLSA build provenance, and a keyless signature over digest-pinned base images, so platform actions are traceable and the running images are verifiable.
Enabled engines
Two-tier tenancy model
Nothi offers two tenancy tiers. Silo, the default, places each organization in its own Kubernetes namespace with default-deny cross-tenant networking, quotas, and limits — the strongest boundary, one database process and volume set per instance. Pool is an opt-in higher-density tier where many organizations share one CloudNativePG cluster as isolated logical databases, each with its own database, dedicated owner and login roles, and public access revoked. One engine, Oracle, is the single exception to per-tenant namespaces: it runs in one shared, elevated-privilege, node-pinned namespace with isolation enforced by a distinct service and credential per database, keeping the elevated blast radius contained while every other engine stays in the standard per-tenant model. Tenant scoping is structural: every API read and write is filtered by the organization on the token, and a cross-tenant lookup returns not-found so existence is never leaked.
Platform security posture
Which database engines does Nothi support?
Twelve engines are enabled today, each with its own validated backup-and-restore path — including PostgreSQL, MySQL and MariaDB, MongoDB, Valkey, Kafka, RabbitMQ, OpenSearch, Qdrant, and Oracle. Engine availability is data-driven: a new engine becomes offerable by enabling it, not by shipping platform code.
How does Nothi keep one tenant's data separate from another's?
By default each organization gets its own Kubernetes namespace with a network policy that blocks cross-tenant connections, a resource quota, and limit ranges, so one tenant can never open a connection into another's database. A denser opt-in Pool tier packs small tenants as isolated logical databases, each with a dedicated owner role and public access revoked.
What stops an accidental database deletion from losing data?
A destructive delete is gated behind a verified final backup and an emailed one-time confirmation code, and fails closed. Any backup failure or timeout preserves the data instead of wiping it, unless an explicit consent bypass is used.
Can platform staff read our databases?
There is no standing access. Database credentials and logs are held only by your own owners and admins, not the platform super-admin. The one route for an operator to reach a tenant database is a per-incident, time-boxed session that requires your approval and a fresh step-up code, is limited to curated read-only actions, and is fully recorded to a transparency log — and it ships switched off by default.
A thirteenth engine, openGauss, is built but not offered. On storage classes that cannot expand, a storage grow is refused up front rather than half-applied.