Databases

Managed PostgreSQL and Redis-compatible key–value storage, created next to your services and connected through environment variables.

What you can create#

Field	Description
PostgreSQL	Relational database for application data: users, orders, content. Supports schemas, indexes, extensions and SQL migrations.
Key–value (Redis-compatible)	In-memory storage for caching, sessions, rate limiting and lightweight queues.
Self-hosted in a container	Any other engine (MySQL, MongoDB, ClickHouse) can run as a private service with a persistent disk attached.

Creating a database#

1
Open the control panel
Go to console.muerte.cloud → Create service → Database.
2
Pick the engine and version
Choose PostgreSQL or a key–value store and the version your app expects.
3
Choose resources and storage size
vCPU, RAM and disk size can be raised later; storage is where your data lives, so leave headroom.
4
Copy the connection string
After creation the panel shows the internal and external connection strings, plus host, port, user and database name.

Put the connection string in an environment variable rather than in code. Use the internal connection string when the service and the database live in the same project — traffic stays inside the private network and is faster.

.env

bash

DATABASE_URL=postgres://user:password@internal-host:5432/appdb
REDIS_URL=redis://internal-host:6379

db.js

import { Pool } from "pg";

export const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  max: 10,
});

Keep the pool small

Managed databases have a connection limit. Several service instances each opening a large pool will exhaust it — size the pool per instance, not per project.

Migrations#

Run migrations in the pre-deploy command so they execute once per release, before the new version starts serving traffic. See how deploys work.

bash

# pre-deploy command
npm run migrate:deploy

External access

The external connection string lets you connect from a local client (psql, DBeaver, TablePlus) for debugging and one-off queries. Prefer the internal address for anything running in production.

Backups and recovery#

Databases are covered by the same backup system as volumes: scheduled or manual copies with configurable retention, restored from any stored copy. Set a schedule before you have real users — see backups.

A code rollback does not roll back data

If a release changed the schema, rolling back the code is not enough — restore data from a backup as well.

Practical notes#

Use the internal host in production

Lower latency, no public exposure.

Index what you filter on

Most slow queries are missing indexes, not missing vCPU.

Separate cache from source of truth

Key–value for sessions and cache, Postgres for data you cannot lose.

Watch disk usage

A full disk stops writes; resize before it fills.

Rotate credentials on offboarding

Regenerate the password when someone loses access.

Test restores

A backup you never restored is an assumption, not a backup.