> ## Documentation Index > Fetch the complete documentation index at: https://paper.brimble.io/llms.txt > Use this file to discover all available pages before exploring further. # High availability databases > Run Postgres, MySQL or MongoDB as a three-node cluster across regions. If the primary goes down, a replica takes over automatically and your app keeps writing. A high availability (HA) database runs as three nodes instead of one: a **primary** that takes writes and two **replicas** that keep a live copy of the data. If the primary goes down, a replica is promoted automatically and your connection string keeps working. Use HA for production databases where a few minutes of downtime from a node or region failure isn't acceptable. ## Availability | | | | - | - | | **Engines** | PostgreSQL 15, 17 and 18, MySQL 8.4, MongoDB 8.0 | | **Plans** | Developer and Team | | **Nodes** | 3: one primary and two replicas | | **Regions** | At least two different regions. Up to two nodes can share a region | | **Minimum memory** | 1 GB per node | ## How it works Each engine uses its own built-in replication: | Engine | Replication | Failover | | - | - | - | | **PostgreSQL** | Streaming replication managed by Patroni | A replica is promoted when the primary stops responding, usually within 30 to 40 seconds | | **MySQL** | Group Replication in single-primary mode | The group elects a new primary, usually within about 10 seconds | | **MongoDB** | Replica set | The replica set elects a new primary, usually within 10 to 15 seconds | Every write goes to the primary and is copied to the replicas. When a failed node comes back, it rejoins the cluster as a replica and catches up on its own. ## Create an HA database 1. Open the dashboard and click **New project → Database**. 2. Pick PostgreSQL, MySQL or MongoDB and a version from the [table above](#availability). 3. Choose the primary region. 4. Turn on **High availability (3 nodes)**. 5. Pick **Secondary region A** and **Secondary region B** for the two replicas. All three can't be in the same region. 6. Set CPU, memory and storage. These apply to **each** node, and memory must be at least 1 GB. 7. Click **Provision Service**. HA is chosen when the database is created. You can't turn an existing single-node database into an HA cluster, or reuse an existing volume for one. To move a single-node database to HA, create a new HA database and restore a [backup](https://paper.brimble.io/databases/deploy-a-database.md#storage-and-durability) into it. > [!TIP] > > For the best protection, put each node in a different region. Nodes that share a region can be affected by the same regional outage. ## Connect to an HA database Use the database's `CONNECTION_STRING` (public) or `PRIVATE_CONNECTION_STRING` (from other Brimble services), the same as a single-node database. The best way is to [link the database](https://paper.brimble.io/databases/deploy-a-database.md#connect-from-a-brimble-service) to your service so the values are wired in for you. The connection string is built so your app always writes to the current primary: * **PostgreSQL** lists all three nodes and adds `target_session_attrs=read-write`, so the driver connects to whichever node is the primary. Your driver must support multiple hosts, for example libpq, `psql`, psycopg, pgx and the PostgreSQL JDBC driver. Node's `pg` package doesn't support multiple hosts. * **MySQL** uses a single host that always points at the current primary. Any MySQL driver works. * **MongoDB** lists all three nodes with the `replicaSet` option. Every official MongoDB driver finds the primary on its own. During a failover, open connections to the old primary drop. Make sure your app reconnects and retries failed queries. Most connection pools do this by default. ### TLS and public access Public access to an HA database requires TLS. If public access is on, TLS is turned on automatically and can't be turned off. Private connections from other Brimble services don't need TLS. ## Monitor the cluster The database's overview shows the **Replication** panel: * Which node is the **Primary** and which are **Replicas**, with the region of each. * **Replication lag**, how far the replicas are behind the primary. After a failover the panel shows the new primary. ## Resize an HA database CPU, memory and storage changes apply to all three nodes. Brimble updates the nodes one at a time, replicas first and the primary last, so the cluster stays up throughout. When the primary's turn comes, Postgres hands the primary role to an updated replica first, and MySQL and MongoDB elect a new primary as the old one restarts. Writes pause briefly while the primary changes. ## Connection pooling (Postgres) Turn on PgBouncer when you create the database or later from its connection pooling settings. On an HA database Brimble runs two PgBouncer instances on different nodes, so pooling keeps working if one of them fails. Both always send queries to the current primary. Use `POOLED_CONNECTION_STRING` (public) or `POOLED_PRIVATE_CONNECTION_STRING` (from other Brimble services). These are single-host strings, so any Postgres driver works, including Node's `pg`. ## Backups and point-in-time recovery Backups work the same as on a single-node database and are taken from the current primary. Restoring a backup or [point-in-time recovery](https://paper.brimble.io/databases/point-in-time-recovery.md) (Postgres) into a new database keeps the HA setup, so a three-node cluster restores into a three-node cluster. ## Cost You're billed for all three nodes. An HA database costs three times the CPU, memory and storage of a single node with the same size. Connection pooling on an HA database is \$4/month for its two PgBouncer instances. The price shown in the create form already includes all of this. ## Limitations * **Created as HA only.** You can't turn HA on or off after the database is created. * **Exactly three nodes.** You can't add more replicas. * **Writes go to the primary.** Replicas aren't exposed as a separate read-only endpoint. * **MySQL: InnoDB only.** Every table needs a primary key, and MyISAM and other non-InnoDB storage engines are blocked. This is required by Group Replication. ## Troubleshooting **"A high availability cluster needs at least 1 GB of memory per node."** Raise memory to 1 GB or more. **"All three nodes can't be in the same region."** Move at least one replica to a different region. **"Choose exactly 2 secondary regions to create a 3-node HA cluster."** Pick a region for both **Secondary region A** and **Secondary region B**. **"This database image does not support HA."** The engine or version you picked doesn't support HA. See [Availability](#availability). **"You can't reuse a volume on a high availability cluster."** HA databases always get new volumes. Create the HA database without a volume, then restore your data into it. **The HA toggle is locked.** HA needs the Developer or Team plan. Upgrade your plan to turn it on. **My app errors for a few seconds and then recovers.** That's a failover. Add reconnect and retry logic so writes during the switch are retried instead of failing. ## Next steps * [Deploy a database](https://paper.brimble.io/databases/deploy-a-database.md), engines, connection strings and regular backups. * [Point-in-time recovery for Postgres](https://paper.brimble.io/databases/point-in-time-recovery.md), restore to any second in the last 7 days. * [Regions](https://paper.brimble.io/projects/regions.md), pick regions for your nodes. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.