Choose storage
Compare environment databases, product-level Postgres and persistent volumes.
Use a managed database for database records and a volume for files your service must retain. A container’s own filesystem is temporary: replacing the container on restart, deployment or rollback loses files written there.
Compare the options
Option | Scope and connection | Use it for |
|---|---|---|
Environment-managed database | PostgreSQL, MySQL, Redis or MongoDB, reachable only within one environment | A database or cache isolated with that environment’s services |
Managed Postgres | Product-level instance with logical databases attached to services across environments | Shared Postgres instances and point-in-time recovery |
Volume | Persistent disk mounted at a path in one service | Uploads, indexes or other application files |
Both managed database options are available under Add service → Databases on the environment canvas. Product-level Managed Postgres is also managed on the Databases page outside the environment navigation.
Connection and recovery differ
An environment-managed database publishes connection values. Reference them from service variables using ${{slug.KEY}}, mark secret references as secret, and redeploy. Managed Postgres attachments instead create secret service variables for you; redeploy to apply them.
Environment-managed databases use whole-database storage snapshots. Managed Postgres backups and restores cover the whole instance, including every logical database on it. Both have seven-day backup retention in the documented configuration. Check the actual backup status before relying on it; database guidance covers restore conditions and interruptions.
A volume keeps its contents across container replacements, but it changes deployment behavior. Only one container can hold the disk, so the old one stops before the replacement starts. Expect an interruption on deploy, restart and rollback. Moving state into a managed database lets your application service use the rollout without a mounted volume; it does not guarantee uninterrupted database operations.
Copies are not backups
Forking an environment copies volume and environment-managed database definitions with empty storage. Secrets and deployment history are omitted. A service rollback restores an earlier image with current variables; it does not restore stored data.
Choose a managed database or a volume to continue with the matching setup and verification steps.