Databases

Supported engines#

Shared versus dedicated#

A shared database is a tenant on a pooled instance: cheaper, quick to provision, and appropriate for development and small workloads. A dedicated database gets its own instance with its own CPU, memory and disk.

The starter tier defaults to shared; standard and pro are always dedicated.

Tiers#

Every database starts with 10 GiB of storage regardless of tier; the tier sets how far it can grow.

Creating a database#

From the console, open the environment’s canvas and add a database. From the CLI:

$ codaracloud databases create main-db \    --engine postgres \    --tier standard \    --client my-workspace \    --project website \    --env production $ codaracloud databases list --client my-workspace

Connecting it to an app#

Connecting a database projects its credentials into the app as environment variables and restarts the app to pick them up. You never copy a password by hand.

$ codaracloud apps connections add my-api main-db --client my-workspace # Rename the injected variables with a prefix$ codaracloud apps connections add my-api cache-db --as CACHE --client my-workspace $ codaracloud apps connections list my-api --client my-workspace

What gets injected#

Postgres:

Redis provides REDIS_URL and its components; MySQL and MariaDB provide MYSQL_URL; MongoDB provides MONGODB_URL. Without --as, the database name is the prefix; when it already matches an engine prefix, keys such as DATABASE_URL and REDIS_URL are not doubled. An explicit --as CACHE namespaces every key, for example CACHE_REDIS_URL and CACHE_PASSWORD.

Connecting from your machine#

To inspect a database locally, open a tunnel through the platform. This needs no cluster access of any kind:

# Opens a local tunnel; Ctrl-C to stop$ codaracloud databases proxy main-db --client my-workspace --local-port 5432 # In another terminal$ psql "postgresql://user:pass@127.0.0.1:5432/main-db"

To see the credentials themselves:

# Masked by default$ codaracloud databases connection main-db --client my-workspace # Show the password and full URL$ codaracloud databases connection main-db --client my-workspace --reveal

An API token needs the db:connect scope to open a tunnel. The scope is available in both the console token screen and the CLI.

Table browser#

The console includes a read-only table browser for Postgres databases — open the database and choose Studio. It lists tables and pages through rows. It is deliberately read-only and does not accept arbitrary SQL; use a tunnel and your own client for that.

Backups#

Check protection on each resource: a supported engine alone does not prove that a recent usable backup exists. Protection depends on the engine, isolation mode and enabled backup configuration. Verify the last successful backup and restore support before relying on it.

Enabled scheduled backups use the database’s configured cron expression; the platform default is daily at 03:00. They are stored in off-provider object storage.

On self-serve plans, backups are kept for at most 7 days. Every restore creates a new database.

Taking a backup on demand#

$ codaracloud databases backup main-db --wait --client my-workspace

This is available for Postgres (shared and dedicated) and dedicated Redis, once per database per UTC day. --wait returns when the backup is a completed recovery point.

Restoring#

A restore always creates a new database — it never overwrites the source. The restore needs temporary capacity while both copies exist. After verifying the restored data, repoint your app at the new database. The commands below work for shared Postgres and dedicated Redis.

$ codaracloud databases restore main-db \    --from <backup-name> \    --as main-db-recovered \    --client my-workspace # Then repoint the app$ codaracloud apps connections rm my-api main-db --client my-workspace$ codaracloud apps connections add my-api main-db-recovered --client my-workspace

Growing a database#

$ codaracloud databases upgrade main-db \    --tier pro \    --storage-size 50Gi \    --client my-workspace

Storage can only grow, never shrink. Databases can also grow their own disk automatically as they approach capacity, up to the tier ceiling.

Deleting a database#

# Shared Postgres: take it offline and retain its data$ codaracloud databases delete main-db --client my-workspace --confirm main-db # Bring the same data back with a fresh credential$ codaracloud databases reactivate main-db --client my-workspace # Permanent shared-Postgres purge (irreversible)$ codaracloud databases delete main-db --client my-workspace --purge --confirm main-db

Normal shared-Postgres removal revokes its credentials and keeps a visible, recoverable retained record. Reactivation uses the same logical database and always generates a fresh password. Permanent purge requires the exact-name confirmation and also erases the database’s backups.

Importing existing data#

Postgres and MariaDB databases can be seeded from a dump file reachable over HTTPS. The import runs as a one-off task inside the platform. This is available through the API and the MCP tools rather than the CLI.

Metrics#

Dedicated databases report CPU, memory and storage on the database page. Shared databases report storage only — CPU and memory belong to the pooled instance and cannot be attributed to a single tenant, so those charts render empty rather than showing a misleading zero.