Highly-available Postgres, without the babysitting

Quickstart

Create the cluster in the dashboard (Console → Clusters → New cluster), pick Database mode and PostgreSQL, choose your node count, and connect to the single endpoint. The endpoint, superuser and database tools all live on the cluster page.

# In the dashboard: Console -> Clusters -> New cluster
#   Mode:    Database
#   Engine:  PostgreSQL
#   Version: 16
#   Nodes:   3        (1 = single, non-HA · 3+ = HA · 2 is not allowed)
#   Plan:    BXS.s1   (each member runs this plan)

# Then connect to the single stable endpoint — writes always
# reach whichever member is the current primary (the superuser
# is 'postgres'; its password is revealed on the cluster page):
psql "postgres://postgres:<password>@203.0.113.10:5432/appdb?sslmode=require"

When to use it

High availability is worth paying for when a database outage would hurt. When it would not, a single managed-DB instance is simpler and cheaper — reach for the cluster when you need failover.

Create a cluster

Three choices decide the shape of the cluster: the engine, the version, and how many members. The one rule to remember is the node count.

Mode:    Database
Engine:  PostgreSQL
Version: 16

Nodes: 3     # 1 = single (no failover)
             # 3 = HA (1 primary + 2 replicas)
             # 2 = not allowed (no safe quorum)

Plan: BXS.s1     # each member runs this plan
# -> members + load balancer + private network

Connect

You connect to the load balancer's public IP on :5432 with sslmode=require. The LB is a TCP passthrough, so TLS runs end-to-end between your client and Postgres. The members themselves are private-only — you never address them directly.

# Same endpoint whether you have 1 member or 5 — it always
# lands on the current primary. TLS is required end-to-end.
# Admin as the 'postgres' superuser (password on the cluster page):
psql "postgres://postgres:<password>@203.0.113.10:5432/appdb?sslmode=require"

# For your app, connect as a least-privilege user you created,
# not the superuser (libpq / most drivers):
DATABASE_URL="postgres://appuser:<password>@203.0.113.10:5432/appdb?sslmode=require"

-- After revealing the superuser (owner-only) you can create
-- app databases and least-privilege users from the dashboard,
-- or with plain SQL over the same connection:

CREATE DATABASE appdb;
CREATE USER appuser WITH PASSWORD 'a-strong-secret';
GRANT ALL PRIVILEGES ON DATABASE appdb TO appuser;

How failover works

Every member runs Postgres plus Patroni, and each keeps a full local copy of the data kept in sync by streaming replication. Patroni elects one member as the primary; the others are replicas. The load balancer only ever routes writes to whoever is currently the leader.

Your app
   │  postgres://postgres:***@<lb-ip>:5432/appdb?sslmode=require
   ▼
┌──────────── Managed Load Balancer · TCP :5432 ────────────┐
│  HAProxy — active check on each member's Patroni /primary  │
│  only the current leader answers 200 -> writes go there    │
└──────┬───────────────────┬────────────────────┬───────────┘
       │ private network    │                    │
       ▼                    ▼                    ▼
  member-1 (PRIMARY)    member-2 (replica)   member-3 (replica)
  Postgres + Patroni    Postgres + Patroni   Postgres + Patroni
  full local copy       full local copy      full local copy
       └──────── streaming replication ──────────►

The routing trick is a single health check: HAProxy polls each member's Patroni /primary REST endpoint, and only the current leader answers 200. So the :5432 endpoint always resolves to the primary, and it follows a failover automatically.

# Before: member-1 is primary, the LB routes :5432 -> member-1
# member-1 crashes ↓

# 1. Patroni notices the leader is gone and elects a new one
# 2. member-2 is promoted to PRIMARY (seconds)
# 3. member-2 now answers 200 on /primary; member-1 does not
# 4. HAProxy's health check moves :5432 traffic to member-2

# Your client: one dropped connection, then reconnect to the
# SAME endpoint — no host change, no config edit. New writes
# land on member-2. The dashboard + Activity tab record the
# role change and a notification fires.

Configuration

Beyond the node count and plan, you can tune the postgresql.parameters that actually change behavior — connection limits, memory, WAL sizing, timeouts — from the cluster's Settings tab or the CLI.

# Cluster page -> Settings tab -> Configuration
#   Max connections:  200     (default: 100 — needs a restart)
#   Work mem:         8MB     (default: 4MB — applies live)

# Or from the CLI:
suble cluster config get my-postgres
suble cluster config set my-postgres work_mem=8MB
suble cluster config set my-postgres max_connections=200
#   -> restart-class change: replicas restart first, the
#      primary last -- no write outage, a brief failover

# Reset a key to its default by setting it to an empty value:
suble cluster config set my-postgres work_mem=

Backups & point-in-time recovery

Replication keeps you online; backups let you go back in time. Suble runs pgBackRest against your own S3 bucket — scheduled full backups plus continuous WAL archiving — so you can restore the cluster to any second in its retention window. HA and backups are different jobs: a replica faithfully copies a dropped table, a backup lets you recover from before the drop.

# Console -> Clusters -> your DB cluster -> Backups tab
#   S3 endpoint:  https://s3.eu-central-1.amazonaws.com
#   Region:       eu-central-1
#   Bucket:       my-suble-backups
#   Path:         /prod-db
#   Access key:   AKIA...
#   Secret key:   ****   (write-once — stored encrypted, never shown again)
#   Schedule:     Daily full backup + continuous WAL archiving
#   Retention:    7 full backups

# Suble initializes the pgBackRest stanza, takes the first full
# backup, and streams WAL to your bucket from then on.

# Backups tab -> Restore. Choose ONE of:
#   Point in time:    2026-07-18 09:30:00   (replay WAL to that second)
#   A specific backup: 20260718-013455F     (restore exactly that one)
#   New cluster:      prod-db-restored

# Suble provisions a brand-new cluster restored to that point and
# brings it up with automatic failover. Your live cluster is never
# touched — restore is always non-destructive. (Ask for a time before
# your earliest backup and Suble tells you the earliest you can reach.)

What it protects against

Replication keeps your database online through failures — but it is not a backup. Understand what each one covers.

Pricing

There is no special "managed Postgres" SKU. A database cluster costs the sum of its parts — the same per-resource meters as everything else on Suble, all metered hourly and capped monthly.

The dashboard shows the live monthly estimate as you size the cluster, and the cluster page breaks the running cost down by members, load balancer and network.