Managed Databases

A managed database is a PostgreSQL or MySQL database that Mengi provisions, runs and backs up for you on one of your Kubernetes clusters. You choose the engine, size and availability tier; Mengi handles the rest and gives you connection details for your apps.

Engines and versions

Engine	Versions
PostgreSQL	18, 17, 16
MySQL	8.4, 8.0

The newest version is selected by default; choose an older one if your app needs it.

Tiers

Tier	What you get	Runs on
Single	One database node. Simple and cheapest; ideal for development and smaller apps.	Any cluster, including shared
High Availability (HA)	Three nodes with automatic failover — if the primary fails, another takes over.	A Dedicated cluster
Replicated	Your database spread across two or more clusters (e.g. different regions): one primary handles writes, the others are read-only standbys you can promote to primary.	Two or more Dedicated clusters

Single runs on any cluster (including the shared tier). HA and Replicated run multiple nodes, so they need Dedicated cluster(s).

Where a database runs

A database runs on the same clusters as your deployments — you pick the cluster (or, for Replicated, the clusters) when you create it, and can create a new cluster inline from the wizard. This means your app and its database can sit in the same cluster for low-latency, private connectivity.

Part 1 — Create a database

Start from New database in the dashboard. The wizard has five steps.

1. Engine

Choose PostgreSQL or MySQL and a version.

2. Tier

Choose Single, High Availability, or Replicated (see Tiers).

3. Cluster(s)

Single / HA — pick one cluster.
Replicated — pick two clusters (the primary’s cluster and the standby’s). You can create a cluster inline if you don’t have one yet.

4. Configuration

Database name — the initial database to create (default app).
Storage — disk size in GB (default 10). Can be increased later.
CPU — cores reserved for the database (default 0.5).
Memory — memory reserved, in MB (default 512).
Max connections — connection limit (default 100).
Backups — on by default (see Backups).
External access — off by default; see Connecting. (Always on for Replicated, since cross-cluster replication needs it.)

5. Review

Confirm and create. The database moves through pending → provisioning → running. Once running, you can fetch its connection details.

Connecting to your database

Once the database is running, open it in the dashboard to see its connection details:

Host and port (5432 for PostgreSQL, 3306 for MySQL)
Database name and username (app)
A connection string (host, user and database — without the password)

The password is not shown on the database page. Instead, the database publishes its credentials as a secret: the database page shows the secret’s name and links to the Secrets page, where the credentials live. The recommended way to use them is to reference that secret from your deployment’s environment variables — the password is injected into your app and never has to be copied around.

Private vs. external access:

Private (default) — the database is reachable only from inside its cluster. Apps deployed to the same cluster connect over the private network — the most secure option.
External access (optional) — enable it to also get a public endpoint (host + port) so you can connect from outside the cluster, e.g. from your laptop or another environment.

Backups

Automatic daily backups run on a schedule and are kept for a retention period (default 7 days).
On-demand backups — trigger a backup yourself at any time, and list the backups that exist.
Backups are stored off-site (separate from the cluster) and sent over an encrypted connection.

Self-service restore from a backup isn’t available in the dashboard yet.

Resizing

You can change these on a running database (the change is applied in place):

Storage — increase the disk size.
CPU and memory — adjust the reserved resources.
Max connections — raise or lower the limit.

High availability & replication

HA tier runs three nodes and fails over automatically if the primary becomes unhealthy.
Replicated tier streams data from the primary cluster to standby cluster(s). Standbys are read-only; if you need to switch over, you can promote a standby to become the new primary from the dashboard.

Deleting a database

Deleting a database removes it and its storage from the cluster. Deleting a member of a Replicated set removes the whole replication group. Deletion is permanent — take a final backup first if you might need the data.

Good to know

Databases bind to the cluster you place them on — keep a database and the app that uses it on the same cluster for private, low-latency access.
HA and Replicated need Dedicated clusters because they run multiple nodes; Single works anywhere.
Pick storage and resources with some headroom — you can scale them up later, but you can’t shrink storage.