Building a High-Availability PostgreSQL Environment with Autobase: What to Check Before Production

Autobase is an open source automation platform that builds and manages high-availability (HA) PostgreSQL environments on your own servers or in your cloud account. It installs Patroni, etcd, PgBouncer, HAProxy, pgBackRest and related components in one consistent Ansible workflow. Its defaults do not suit every environment, though: synchronous replication, backups and the firewall are all off by default. In this article we explain what we check before taking a high-availability environment built with Autobase to production.

At Aryasoft we use Autobase to build high-availability PostgreSQL environments. The typical risks of hand-built environments, such as configuration drifting between servers, inconsistent timeout settings and skipped steps, largely disappear with repeatable automation. Automation does not replace the right decisions, however, and this article goes through those decisions one by one. The details are based on Autobase 2.11.0 and its official documentation.

At a Glance: What Is Autobase?

Components Autobase Installs

A high-availability PostgreSQL environment is not a single piece of software. Autobase installs the following parts, wired together with consistent settings:

Choose the Right Architecture: Three Deployment Schemes

Autobase offers three architectures. The first decision is how your applications will connect.

To get value from the load-balancing scheme, the application must be able to send read queries to a separate address. Without that capability the replicas stay standby servers only, so make the architecture decision together with the application team.

10 Things We Check Before Going to Production

Autobase’s defaults are designed for a quick start. The table below summarizes the settings we review on every production deployment and why.

We explain each one below.

1. DCS: an odd number of members, separate servers, separate disks

etcd is the “brain” of the cluster: it decides which server is the primary. To make decisions, a majority of its members (a quorum) must be up. That is why the member count should be odd: 3 members survive one failure, 5 members survive two.

The Autobase documentation makes three recommendations: keep DCS data on a disk separate from PostgreSQL data (SSD if possible), deploy the DCS cluster on servers separate from the database servers, and do not place all DCS members in a single data center. In small environments etcd can run on the database servers; a busy database, however, can keep etcd from responding in time and trigger unnecessary failovers.

2. Synchronous replication: define your tolerance for data loss

For performance reasons, Autobase deploys with synchronous replication off. If the primary goes down unexpectedly in that state, the last transactions that had not yet reached a replica can be lost. Patroni limits this risk by not promoting a replica that is more than 1 MB behind (maximum_lag_on_failover), but it does not remove it.

We recommend synchronous mode where data loss is unacceptable, such as finance and payment systems. We use strict mode only in environments with at least two replicas; otherwise a single replica failure stops the application.

3. Backups: off by default

This is the setting that costs the most when it is overlooked. If neither pgBackRest nor WAL-G is installed, Autobase sets the archive command to a no-op, so WAL is not archived and point-in-time recovery is impossible. Replication is not a backup: a table dropped by mistake on the primary disappears from every replica within seconds.

Turn on pgBackRest with pgbackrest_install: true and send backups to a repository outside the cluster: a separate backup server, S3-compatible object storage, Azure Blob or Google Cloud Storage. The example schedule in the documentation is a full backup on Sundays, differential backups on the other days and incremental backups every four hours. Set retention according to your RPO target and regulatory obligations.

4. Firewall: close it at the network layer

By default Autobase does not enable the operating system firewall and disables firewalld and ufw. This assumes network security is provided at another layer. In enterprise environments that layer is usually the network firewall or cloud security groups. Whichever you use, open only the required ports, and only to the sources that need them:

The Patroni REST API and the etcd ports are the cluster’s control plane; do not expose them to the application network or the internet.

5. Locale: get language-specific data right from day one

Autobase creates the cluster with the en_US.UTF-8 locale by default. For many languages this is fine; for Turkish, for example, it converts “i” and “ı” to the wrong upper and lower case and does not sort in Turkish alphabetical order. Because a database’s locale cannot be changed later, decide before deployment: set the postgresql_locale variable accordingly, or create application databases with an ICU collation for the language. We cover the details with examples in our What Is PostgreSQL? guide.

6. PgBouncer: choose the pool mode for the application

PgBouncer is installed in session mode with a pool of 100 connections per database. Session mode is the most compatible option, but each client connection holds a database connection for the whole session. If you have many clients running short transactions, transaction mode is far more efficient; however, features that keep session-level state (such as SET commands meant to last for the session, or temporary tables) may not behave as expected in that mode. Choose the mode by testing the application’s behavior.

7. Memory settings: calculate them together with the connection count

Autobase sets shared_buffers to 25% of RAM and effective_cache_size to 75%, in line with the PostgreSQL documentation. The setting to watch is work_mem: the 64 MB default can be used separately by each sort or hash operation in a single query. With max_connections at 1000 by default, total memory use at peak can exceed the server’s capacity. Size these two values together, based on the real number of concurrent connections and the query profile.

8. TLS: plan your certificate

Autobase generates a self-signed certificate valid for 10 years to encrypt connections and sets the minimum TLS version to 1.2. Encryption works as it is. If clients must verify the server’s identity (sslmode=verify-full), replace it with a certificate issued by your organization’s certificate authority.

9. Passwords: never leave them as plain text in the variables file

Autobase does not generate user passwords; you define them in the group_vars file. Because these files usually live in a Git repository, do not leave passwords in plain text; manage them with an encryption method such as Ansible Vault or your corporate password manager.

10. Test before go-live

Automation builds the environment, but it does not prove that it behaves as expected. Our acceptance tests include:

• Planned switchover: measuring how many seconds of interruption a leader change causes on the application side.
• Failure scenario: shutting down the primary unexpectedly and confirming automatic failover.
• DCS failure: shutting down one etcd member and confirming that the cluster keeps running.
• Restore: point-in-time recovery from a pgBackRest backup to a separate server.

Command-Line Deployment in Outline

Besides the web UI, you can run Autobase from the command line with a Docker image that bundles every dependency. The flow has three steps:

1. Prepare the inventory file. Download the example file and place your servers in groups: [etcd_cluster] (DCS members), [master] (the initial primary), [replica] (replicas), and if needed [balancers] (HAProxy) and [pgbackrest] (backup server).
2. Set the variables. Define the decisions above in group_vars/all.yml: scheme, synchronous mode, backups, locale, passwords.
3. Run the deployment.

curl -fsSL \
  https://raw.githubusercontent.com/autobase-tech/autobase/refs/tags/2.11.0/automation/inventory.example \
  --output ./inventory
mkdir -p ./group_vars
nano ./group_vars/all.yml

docker run --rm -it \
  -e ANSIBLE_SSH_ARGS="-F none" \
  -e ANSIBLE_INVENTORY=/project/inventory \
  -v $PWD:/project \
  -v $HOME/.ssh:/root/.ssh \
  autobase/automation:2.11.0 \
  ansible-playbook deploy_pgcluster.yml

A starting group_vars/all.yml that reflects our decisions could look like this:

postgresql_version: "18"
synchronous_mode: true
synchronous_mode_strict: false
pgbackrest_install: true
pgbouncer_install: true
ntp_enabled: true

Add the values specific to your environment (server addresses, backup repository, locale, passwords) following the comments in the default variables file.

After Deployment: Maintenance and Upgrades

Autobase’s real value shows after deployment. The riskiest day-to-day operations come as ready, controlled workflows:

Before a minor update starts, Autobase runs safety checks: replication is working, lag is below 10 MB and no transaction has been running for more than 15 seconds. For a major upgrade we recommend running the pre-check first, which changes nothing. In environments without PgBouncer, traffic is not redirected to the new primary automatically; applications must be stopped and the connection address changed by hand.

What Automation Does Not Replace

Autobase greatly reduces human error in deployment and maintenance. Some decisions and responsibilities always stay with your team, though:

• Architecture decisions: RPO and RTO targets, data center placement, the choice of synchronous replication.
• Monitoring and alerting: alerts for replication lag, disk usage, backup success, transaction ID age (wraparound) and slow queries.
• Performance: query and index tuning, autovacuum settings, capacity planning.
• Regular drills: repeating failover and restore tests periodically.

For the broader rules of running PostgreSQL in production, see our PostgreSQL best practices guide.

High-Availability PostgreSQL with Aryasoft

Aryasoft’s senior-only team builds high-availability PostgreSQL environments with Autobase end to end: architecture design, DCS placement, synchronous replication and backup decisions, security hardening, failover and restore tests. Every decision and test result is handed over in writing. If you want your environment looked after once it is live, see our managed database services, which include a remote DBA service.

Frequently Asked Questions

Sources

The details in this article were checked against the Autobase 2.11.0 documentation and source code in November 2026. Default values can change in new releases; check the variables file of the version you use before deploying.

1. Autobase: GitHub repository
2. Autobase: default variables (defaults/main.yml)
3. Autobase documentation: Architecture
4. Autobase documentation: Requirements
5. Autobase documentation: Recommendations
6. Autobase documentation: Your Own Machines
7. Autobase documentation: Backup
8. Autobase documentation: Upgrades
9. Patroni documentation
10. etcd: FAQ (cluster size and quorum)
11. PostgreSQL documentation: Resource Consumption
12. PgBouncer: Features (pool modes)