More time for the thing you’re building. Explore Cloud beta
HakopodHakopod
Create account
Development releaseRead the release notes
PostgreSQL + Redis / Managed in Cloud

Your app and its data.
One Cloud dashboard.

Keep deployment, private connections and database recovery in one place. Managed databases give you verified backups and a separate copy to inspect before you switch your app.

See how recovery works
A shape for your dataConcept illustration

PostgreSQL standalone

Your application Its own replica count
Private connection
Database

One database instance, with its own resources and lifecycle.

PostgreSQL cluster

Your application Its own replica count
Private read/write · Private read-only
Primary
Replica
Replica

A primary and replicas. The database controller manages replication and primary recovery.

Redis standalone

Your application Its own replica count
Private connection
Redis

One Redis instance. Back up values and expiry to an eligible S3 destination.

Redis cluster

Your application Its own replica count
Private cluster discovery
Shard 1 + replica
Shard 2 + replica
Shard 3 + replica

Data is distributed across shards, each with a replica in this example. Your app needs a cluster-aware client.

Illustrative topology, not live cluster state. Replicas still need capacity and separate failure domains for availability.

Scale apps independentlyCheck restored data firstChoose when to switch
01 / Room for your data to grow

Choose your database setup.
Keep app scaling separate.

PostgreSQL 17 / 18

PostgreSQL replicas.
Private reads and writes.

Start standalone or choose a primary with replicas. Private read/write and read-only endpoints give your application clear ways to connect. The database controller handles replication and primary recovery.

Scaling your app does not change the database’s replica count.

Redis 8

Add or remove shards.
Review the change first.

Run standalone or distribute data across shards with replicas. Grow or reduce the shard count after reviewing the change and taking a verified recent backup. Resizing checks real cluster health and slot ownership.

Redis Cluster needs a cluster-aware client.

A cluster needs enough compute and storage. Replicas on a single worker or VM do not provide availability if that worker, VM or shared disk is lost.

02 / Recovery you can inspect

Check the restored data.
Then switch your app.

Restore into a separate database. Your source stays available while you inspect the copy. Replace the saved app connection and redeploy only after that review.

Your original databaseStill here.Source data stays available
  1. 01

    Restore.

    A verified archive.
    A separate database.

  2. 02

    Inspect.

    Check the recovered data.
    Acknowledge your review.

  3. 03

    Switch.

    Replace the saved connection.
    Redeploy your application.

A copy has a point in time. Writes made after that point do not follow it automatically. Coordinate writes and take a fresh capture before final cutover when needed.

03 / The work around your data

Back up. Import. Upgrade.
Keep building.

Keep a recovery point

Scheduled backups.
Your S3 destination.

Choose an eligible S3 destination for manual, hourly or daily PostgreSQL and Redis backups. Restore from a verified archive when you need a separate copy.

Redis preserves values and expiry. Archives are consistent per shard, not one transaction across the cluster.

Bring what you have

Bring a Docker backup.
Keep the source in place.

Import an eligible PostgreSQL or Redis backup while the original application stays on Docker. Check the imported database before replacing your application’s connection.

Check supported imports
Try the next version

Try PostgreSQL 18.
Inspect the upgraded copy.

Stage the upgrade as a separate logical copy. Inspect it before choosing a final recovery point and changing the application connection.

The source stays available. This is a staged migration, not an in-place upgrade.

Development evidence

Tested recovery paths.
Evidence you can read.

  • PostgreSQL recoveryPrimary recovery retained a test row; a separate 17-to-18 logical copy was restored and inspected.
  • Redis resizingA real cluster grew from three to four shards and returned to three, preserving tested values and expiry.
  • Archive recoveryVerified archives restored into separate targets. Corrupt archives and stale recovery evidence were rejected.

These checks ran on development infrastructure. They do not establish production availability or an uptime guarantee.

Read the development acceptance record
Before you start

Before you create
your Cloud account.

Can I use managed databases in Cloud today?

Yes, in eligible hosted workspaces with enough compute and storage. A Free allocation may fit a standalone database but not a cluster. Signup starts Cloud onboarding; it does not guarantee immediate compute. Self-hosted and BYO installations need operator setup.

Do I have to move my current database immediately?

No. Import an eligible Docker backup into a separate managed database while the source stays available. Inspect the copy before replacing your app’s connection. Changes after the capture point need a fresh capture before final cutover.

Does “clustered” remove the need to plan for outages?

No. Replicas need enough compute and storage. A cluster on one worker or VM cannot remain available if that worker, VM or its shared disk is lost. Redis Cluster also requires a cluster-aware client.

What does Cloud cost?

The published Cloud BYOD launch plans describe dashboard and control-plane pricing; your provider’s compute is separate. Paid checkout is not open yet. This release announces no new database price or guaranteed allocation.