LiveKubernetes-native managed database platform

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.

ISO/IEC 27001:2022 · ISO 9001:2015 — certifications

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.

Nothi tenant dashboard: databases running, fleet health, spend and hourly burn, activity feed, and live resource usage across the fleet.
Tenant dashboard, fleet health, spend, and live utilisation. Tenant name masked.
Nothi instance metrics: connections, transactions per second, cache hit rate, deadlocks, replication lag and database size, with CPU and memory charts.
Instance console, per-database performance, backups, logs, and connection details.
01

What Nothi does

LIVE
Catalog-driven engine discovery

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.

LIVE
One lifecycle, every engine

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.

LIVE
Namespace-per-tenant isolation

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.

LIVE
Shared Pool density tier

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.

LIVE
Per-engine backup and restore

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.

LIVE
Fail-closed delete gate

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.

LIVEships dormant
Governed DBA access envelope

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.

LIVE
Credential and log lockdown

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.

LIVE
Mandatory two-factor auth

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.

LIVE
Per-tenant OIDC single sign-on

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.

LIVE
Usage-metered billing loop

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.

LIVE
Audit trail and supply-chain integrity

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.

02

Enabled engines

PostgreSQLCloudNativePG: HA streaming replication, automatic failover, and Barman-based backups.
EDB Postgres AdvancedThe enterprise PostgreSQL tier on the same operator via a licensed image; entitlement-gated.
MySQLPercona XtraDB Cluster: Galera multi-primary clustering behind a proxy.
MariaDBThe community mariadb-operator with Galera clustering.
MySQL CommunityOracle's MySQL Operator running InnoDB Cluster with Group Replication.
MongoDBPercona Server for MongoDB, always provisioned as a replica set.
ValkeyThe open-source Redis-compatible cache, with Sentinel-based replication.
Apache KafkaStrimzi in KRaft mode, no ZooKeeper.
RabbitMQThe RabbitMQ Cluster Operator running a quorum cluster.
OpenSearchThe OpenSearch operator, offered in HA (multi-node) form only.
Oracle Database (Enterprise)Oracle's OraOperator with Data Pump logical backups; entitlement-gated and fleet-capped.
QdrantA vector database for AI, semantic search, and RAG; operator-less and standalone.
Pool tierNot a separate engine: many tenants share one CloudNativePG cluster as isolated logical databases for higher density.
03

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.

04

Platform security posture

CIS-hardened KubernetesRuns on RKE2 under the CIS profile, with control-plane pods non-root, read-only root filesystem, and all Linux capabilities dropped.
Enforced Pod SecurityControl-plane workloads run under the restricted Pod Security Standard, and tenant namespaces bar privileged, host-network, and host-path pods; the two newest engines were engineered to run non-root rather than take elevated privileges.
Default-deny networkingThe control-plane namespace denies ingress and egress by default, re-opening only the specific paths the platform needs, and the control-plane API is reachable only through the reverse proxy, never directly.
Edge web application firewallA ModSecurity plus OWASP Core Rule Set firewall inspects ingress traffic.
Fail-closed by designMissing entitlements, unconfigured encryption keys, empty version catalogs, and unresolvable identity hosts all deny rather than fall back to a permissive path.
Supply-chain attestationRelease images ship with an SBOM, SLSA build provenance, keyless signatures, and digest-pinned base images.
Common questions

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.

Limits

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.

See Nothi run on your own cluster.

Request a demo