Skip to main content
A databases: entry declares a database the project needs. slipway pins the image, attaches a disk, generates a password and wires it into the project like any other service.
slipway.yaml
A database is a service. It takes a name in the project, siblings reach it by that name, and it appears in the console with its own Credentials, Metrics and Backups tabs. Declaring it under databases: rather than services: saves you the image tag, the credential environment, the disk path and the readiness probe.

​
Fields

Quote the version. Unquoted, YAML reads 8.0 as a number and loses the trailing zero.

​
Engines

latest is not a valid version. A managed database has to be reproducible, so the tag is always pinned. The memory floor is the smallest allocation the engine runs on. If you configure less, the deploy fails rather than silently raising it. redis is the only engine that may omit diskSizeGB, because a cache with no persistence is a legitimate thing to want. Every other engine requires a disk, since a database that loses its data on restart is rarely what anyone means. An allocation below an engine’s memory floor fails the parse and names the number, rather than being raised silently. Raising it would increase what the service costs without you choosing it.

​
The password

The first deploy generates a strong password and stores it as a project secret named after the database, uppercased: db becomes DB_PASSWORD, and main-cache becomes MAIN_CACHE_PASSWORD. Later deploys reuse it. The deploy records a database_secret_provisioned event naming the secret, never the value. Nothing about the password is in your repository. Reference it like any other secret if your app needs it separately from the connection string:
slipway.yaml
With the right role you can read and rotate it from the database’s Credentials tab.

​
Connecting

A sibling reaches the database by bare name, and ${service.<name>.url} resolves to a full connection string with credentials already in it:
slipway.yaml
The individual pieces are available too: host, port, user, password, database, and external_url once external access is on. See the per-engine pages for what each contains: Postgres, Redis, MySQL, ClickHouse. To make a service wait for the database before starting, name it in dependsOn:
slipway.yaml

​
Version changes

A managed database keeps the version it was created with. The image tag and the on-disk data format are the same decision, and an engine will not start against a data directory written by a newer major version. To move version, create a new instance on the new version and migrate the data into it with the engine’s own dump and restore tools.

​
Data, backups and cost

The disk is an ordinary disk. It survives redeploys, can be snapshotted and restored in place, and can back itself up on a schedule. It can be grown later from the service’s Disks tab without a restart, but never shrunk. You are billed for the database’s compute allocation like any other service, plus its provisioned storage. A database is not exposed to the internet. External access is a deliberate toggle on its console page, not something the spec turns on.
Declaring the same engine by hand under services: still works, with image:, a password env and a disk:. The databases: block is that, with the details filled in, and it is what the console’s own Database page creates.