Databases

Orbit runs PostgreSQL, MySQL 8.4 and Redis 7.4 next to your applications, each with a volume on the server's disk under /var/lib/rancher/k3s/storage. New PostgreSQL databases run on CloudNativePG.

The data lives on a server's disk

If that server is lost, so is the data, unless backups go to external storage. Storage sizes are requested, not enforced.

Connecting applications

• Only applications in the same environment can connect. The address is <name>.orbit-<project>-<environment>.svc.cluster.local. Orbit creates the database and its user with the service's name (- becomes _) and a random password.
• Connect on an application adds a reference such as DATABASE_URL to its variables. The value is filled in when the application deploys, so redeploy it after connecting. The database's page lists the applications that use it.

Connecting from your computer

Show credentials on the database's page reveals the user, password and database with two ways in:

• An SSH tunnel through the main server, which keeps the database private: run the command it shows, then connect psql, DBeaver or TablePlus to 127.0.0.1:15432 (13306 for MySQL, 16379 for Redis).
• The public address, when access is public.

Every reveal is recorded in Activity.

Browsing data

Browse data opens the tables, with their estimated rows and size, and pages through their rows. For Redis it scans the keys by pattern and shows each value by type.

• Queries: the Query tab runs one SQL statement (a SELECT, WITH, VALUES or TABLE) in a read-only transaction. It stops after 15 seconds, returns up to 500 rows and cuts cells at 1,000 characters. Every query is recorded in Activity with its text.
• Read-only is a guard, not a permission: a statement that writes is refused before it runs, and the transaction catches the rest. To change data, connect from your computer.

Public access

Making a database public publishes it on the server's IP at the engine's port (5432, 3306 or 6379, or the next free one). Open that port in your provider's firewall only for the addresses that need it, and make the database private again when they no longer do.

Rotating credentials

Orbit changes the password, updates every application that uses the database (including the releases kept for rollbacks) and restarts them, then checks that the old password is refused. Applications that read the password from anywhere other than their Orbit variables have to be updated by hand.

Upgrading

Orbit backs the database up first, then runs the new version and checks that it holds the same tables and rows (or keys).

• On CloudNativePG, PostgreSQL upgrades in place with pg_upgrade, and the previous version comes back if that fails.
• On the older StatefulSet runtime, moving PostgreSQL to a new major version restores the backup into a new volume, so it takes about as long as a restore. A failed upgrade starts the previous version again on its own data.

PostgreSQL on CloudNativePG

Orbit installs the CloudNativePG operator and its Barman Cloud plugin when the first PostgreSQL database is created. CloudNativePG brings replicas on other servers and point-in-time recovery.

Moving an older database: a PostgreSQL database created before CloudNativePG shows Move to CloudNativePG on its page. The preview says how long writes pause, where the backup goes, whether the server has the disk for a second copy, and that the current volume is kept.

1. Orbit backs the database up.
2. It starts the cluster next to the current database.
3. It pauses writes (reads keep working) and copies the data, checking that the cluster holds the same tables and rows.
4. It points the address the applications use to the cluster and restarts them, with the same variables.

If a step fails, Orbit removes the cluster and the old database accepts writes again. The old volume stays on the server, frozen and read-only, until Remove old volume.

MySQL

• It needs at least 512 MB.
• The application's user only reaches its own database. A local root, whose password Orbit keeps and never shows, runs backups, restores and password changes.
• A restore first checks that the dump is complete and loads it into a staging database, and only then replaces the live one, so a broken backup leaves the data as it was.

Looking inside

sudo k3s kubectl -n orbit-<project>-<environment> get clusters.postgresql.cnpg.io,pods,pvc
sudo k3s kubectl -n orbit-<project>-<environment> exec -it <name>-1 -c postgres -- sh -c 'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB"'