Skip to main content

Architecture

Autobase Console​

Autobase Console is the web-based platform for managing the lifecycle of PostgreSQL clusters. It consists of the Console UI, Console API, and Console DB.

autobase-platform-schemeautobase-platform-scheme
  • Console UI provides a web interface for creating clusters, launching operations, and monitoring status.
  • Console API receives requests from the UI, stores and reads data from the Console DB, and triggers automation tasks when required.
  • Console DB stores cluster metadata, server information, settings, operation results, and current status.

Console and Automation are tightly integrated: users perform actions in the UI, the API prepares the required inventory and variables, and the Automation container runs Ansible playbooks to deploy, configure, or maintain PostgreSQL clusters. Operation results are persisted in the Console DB and displayed back in the UI.

PostgreSQL Cluster​

Autobase supports three deployment schemes:

1. High-Availability Only​

This is a basic high-availability scheme without load balancing.

postgres-ha-schemepostgres-ha-scheme

Components:​

  • Patroni is a template for building customized PostgreSQL high-availability solutions using a distributed configuration store such as etcd, Consul, or ZooKeeper. Patroni runs on each PostgreSQL node, continuously monitors the local PostgreSQL instance, and coordinates cluster state through the DCS. The node that holds the leader lock acts as the primary; if it becomes unavailable, eligible replicas participate in a leader race, and the first one that acquires the leader lock promotes itself to the new primary.

  • etcd is a reliable distributed key-value store for critical data in distributed systems. etcd is written in Go and uses the Raft consensus algorithm to manage a highly available replicated log. Patroni uses etcd to store cluster state and PostgreSQL configuration parameters. What is Distributed Consensus?

Optional:

  • vip-manager runs on all cluster nodes and connects to the DCS. If the local node owns the leader key, vip-manager starts the configured VIP. During failover, vip-manager removes the VIP from the old leader, and the service on the new leader starts it there. It provides a single entry point (VIP) for database access. It is not available for cloud environments.

  • PgBouncer is a connection pooler for PostgreSQL. It is useful when applications create many short-lived connections or when the number of client connections is higher than PostgreSQL should handle directly. PgBouncer reuses server-side connections, reduces connection overhead, and helps protect PostgreSQL from connection spikes.

2. High-Availability with Load Balancing​

This scheme enables load distribution for read operations and allows the cluster to scale out with read-only replicas.

postgres-ha-lb-schemepostgres-ha-lb-scheme

When deploying to cloud providers such as AWS, GCP, Azure, DigitalOcean, and Hetzner Cloud, a cloud load balancer is automatically created by default to provide a single entry point to the database.

For non-cloud environments, such as Your Own Machines deployments, the HAProxy load balancer is available.
List of ports when using HAProxy:

  • port 5000 (read/write primary)
  • port 5001 (read-only, all replicas)
  • port 5002 (read-only, synchronous replica only)
  • port 5003 (read-only, asynchronous replicas only)
info

Your application must support sending read requests to a custom address and port.

Components:​

  • HAProxy is a fast and reliable solution for high availability, load balancing, and proxying for TCP and HTTP-based applications.

Optional:

  • confd manages local application configuration files using templates and data from etcd or Consul. It is used to automate HAProxy configuration management.

  • Keepalived provides a highly available virtual IP address (VIP) and a single entry point for database access. It implements VRRP (Virtual Router Redundancy Protocol) for Linux. In the Autobase configuration, Keepalived checks the status of the HAProxy service and, in case of failure, moves the VIP to another server in the cluster. It is not available for cloud environments.

3. High-Availability with Consul Service Discovery​

In this scheme, Consul Service Discovery with DNS resolution is used as a client access point to the database.

postgres-ha-consul-schemepostgres-ha-consul-scheme

It is also suitable for primary access and read load balancing across replicas using DNS. Example:

  • primary.postgres-cluster-01.service.consul
  • replica.postgres-cluster-01.service.consul

This scheme can also be useful for distributed clusters across multiple data centers. You can specify the data center where each database server is located, then use that information for applications running in the same data center. Example:

  • replica.postgres-cluster-01.service.dc1.consul
  • replica.postgres-cluster-01.service.dc2.consul

It requires Consul in client mode on each application server for service DNS resolution. Alternatively, use DNS forwarding to a remote Consul server instead of installing a local Consul client.