Managed PostgreSQL and Redis
Independent PostgreSQL and Redis databases, verified backups and staged recovery before application cutover.
Development release. Available in eligible hosted Cloud workspaces. Compute and storage limits apply. Managed databases are included in self-hosted alpha.37 with separate operator setup for controllers, storage and placement. Follow the database overview for a visual explanation.
Give the database its own lifecycle#
Managed PostgreSQL 17/18 and Redis 8 are separate resources with their own allocation, progress, credentials and lifecycle. Application replica counts do not control database replication or failover. Connecting a database updates the application's saved connection and requires a redeployment.
| Engine | Standalone | Clustered |
|---|---|---|
| PostgreSQL | One database instance. | A primary and replicas, primary recovery, and private read/write and read-only endpoints. |
| Redis | One Redis instance. | Data distributed across shards, with replicas. Requires a cluster-aware client. |
Replicas need real compute and storage. A cluster on one worker or VM cannot remain available if that worker, VM or its shared disk is lost.
Review a Redis resize#
Grow or reduce the shard count only after reviewing the proposed allocation and taking a verified recent backup. The implementation checks real cluster health and slot ownership before resizing and waits for the resulting topology. Application replica changes never resize the Redis cluster.
Back up to a destination you choose#
Configure an eligible S3-compatible destination for manual, hourly or daily backups. Backups are verified archives, separate from database replicas. Redis archives preserve values and expiry. Each shard is captured consistently; the entire cluster is not captured as one transaction.
Restore, inspect, then switch#
- Restore a verified archive into a separate managed database. The source stays available.
- Inspect the restored data and acknowledge that review before replacing a connection.
- Switch deliberately by explicitly replacing the application's saved connection, then redeploying it.
The copy reflects the captured recovery point. New writes do not follow it automatically. Coordinate application writes and take a fresh capture when needed before final cutover. This is not a promise of zero downtime or automatic continuous migration.
Import from Docker or stage a PostgreSQL upgrade#
Import an eligible Docker PostgreSQL or Redis archive while the original application remains on Docker. The archive must match its reviewed metadata and checksum. PostgreSQL 17-to-18 upgrades use a separate logical copy for checking before connection replacement. See the pinned implementation guide for eligible archive formats, destination requirements, limits and controller installation.
Cloud capacity and setup#
Hosted Cloud integrates workspace memory/storage quotas, trusted placement and required approvals. Capacity determines which topology fits; a Free allocation may fit a standalone database but not a cluster. Account signup does not guarantee compute allocation. Self-hosted and BYO installations require operator setup of the matching engine, pinned database controllers, worker runtime and storage.
Cloud BYO relay archive uploads are not supported by this implementation. Use the direct node HTTPS API with the CLI. No new plan price or launch date is announced here.