Autobase for PostgreSQL: an internal DBaaS built on Ansible

The gap Autobase fills between raw Patroni and a cloud DBaaS

Running highly available PostgreSQL yourself means assembling several moving parts: a failover manager, a connection router, a backup schedule, a restore procedure, and an upgrade path that does not take the primary down for an hour. Cloud providers sell that assembly as a service. Autobase's pitch is to deliver the same experience inside infrastructure you already own. The README calls it an "Internal Database Platform for PostgreSQL" and frames the goal as bringing "the managed database experience of DBaaS into your own infrastructure".

The intended audience is stated plainly: teams that want production-ready clusters but lack "specialized expertise". That is a narrower claim than it sounds. Autobase does not remove the need to understand PostgreSQL replication; it removes the need to write the automation that wires it together. The repository topics list patroni, auto-failover and high-availibility, which tells you what sits underneath. If you already have a working Patroni setup with tested runbooks, Autobase is mostly a packaging and interface change. If you are starting from a single postgres process and a cron job for pg_dump, the distance it covers is much larger.

What the cluster components and the three deployment paths actually are

The README points to an Architecture page for "a detailed description of the cluster components" and ships a diagram image, but the text itself does not enumerate them. What can be confirmed from the material is the shape of the product: a PostgreSQL cluster with automated failover, backups, restore, upgrades and scaling, driven by an automation layer. The topics list names Patroni, so failover management is delegated to an established tool rather than reinvented.

There are three ways to drive that layer. The Console is a UI, split into a Community Edition described as a "free license for individual developers and hobby projects" with "lightweight cluster deployment", and an Enterprise Edition described as a "commercial license for production environments" with "extended cluster management features and support". The Ansible Collection is the raw automation, aimed at teams who "prefer Ansible playbooks instead of the database platform". GitOps is the third path: cluster configuration lives in Git and changes are applied through CI/CD pipelines.

That three-way split is the most consequential design decision in the project, and it is not fully resolved by the README. The collection is MIT-licensed, the console is licence-gated, and the boundary between the two is described only in marketing terms ("lightweight" versus "extended"). Anyone planning a production rollout needs to read the Community Edition README under ./console/ before assuming the free path covers their use case.

Installing it: Ansible collection, console, or GitOps

The README does not inline installation commands. It routes you to three separate documents: ./console/README.md for the Community Edition, ./automation/README.md for the Ansible Collection, and the GitOps page at autobase.tech/docs/management/gitops. That is a documentation layout choice worth noting, because it means the entry point depends on which of the three modes you pick, and there is no single quickstart that covers all of them.

The Ansible path is the one with the most visible structure in the repository. The CI badges show ansible-lint, yamllint, flake8 and Molecule workflows, which means the playbooks and roles are linted and tested with Molecule scenarios as part of the build. For a team that already runs Ansible, that is a meaningful signal about how the automation is maintained, because Molecule scenarios are how role authors verify converge and idempotence behaviour rather than just syntax.

The compatibility list constrains the inventory you can target. Red Hat and Debian based distributions only: Debian 11, 12 and 13; Ubuntu 22.04, 24.04 and 26.04; CentOS Stream 9 and 10; Oracle Linux 8, 9 and 10; Rocky Linux 8, 9 and 10; AlmaLinux 8, 9 and 10. Architectures are x86_64 (amd64) and aarch64 (arm64). PostgreSQL versions are listed as "all supported", with a tested set of 10 through 18. The README also publishes a table of daily automated cluster deployment tests, one workflow per distribution, covering Debian 12 and 13, Ubuntu 24.04 and 26.04, CentOS Stream 9 and 10, Oracle Linux 9 and 10, Rocky Linux 9 and 10, and AlmaLinux 9 and 10. Note the asymmetry: the compatibility list includes Debian 11 and Oracle Linux 8, but the daily test table starts at Debian 12 and Oracle Linux 9. If you are on one of the older entries, you are outside the tested matrix.

Where Autobase is the wrong choice

The compatibility list is the hard boundary. No SUSE, no Amazon Linux, no FreeBSD, no Windows. If your fleet is built on SLES or you run PostgreSQL on Windows Server, Autobase has nothing for you and the MIT licence does not change that, because the limitation is in the automation targets, not the licence terms.

The second boundary is the console licence split. The README describes the Community Edition as free "for individual developers and hobby projects" and the Enterprise Edition as the commercial option "for production environments". A team that wants a UI for production clusters and expects that to be free is likely to be disappointed. The honest reading is that the Ansible collection is the open component and the console is the commercial surface. If you want a fully open control plane, the collection is your path, and you should expect to build your own interface on top of it.

The third case is orchestration. Autobase automates PostgreSQL on hosts it manages via Ansible. If your infrastructure is Kubernetes and your team already runs operators, adding an Ansible-based host-level platform creates a second control plane to reason about, with its own state, its own credentials and its own failure modes. The README does not describe a Kubernetes operator, so there is no indication that Autobase integrates with that model rather than competing with it.

Patroni and CloudNativePG: two different answers to the same question

Since the repository topics name Patroni, the fairest comparison is with Patroni used directly. Patroni is a template and configuration system for building highly available PostgreSQL clusters: you supply the cluster topology, the DCS backend (etcd, Consul, ZooKeeper or Kubernetes), and the bootstrap configuration, and Patroni handles leader election and promotion. Autobase takes that and adds the deployment layer, the backup and restore workflow, the upgrade path and the UI on top. The difference in approach is that Patroni assumes you will write and maintain the surrounding automation, while Autobase assumes you want that automation shipped as linted, Molecule-tested Ansible roles. The trade is control for convenience: Patroni gives you every knob, Autobase gives you a smaller set of decisions with defaults already made.

The second alternative is CloudNativePG, which runs PostgreSQL inside Kubernetes and uses the Kubernetes API server as its source of truth for cluster state. That is a fundamentally different model from Autobase's host-based Ansible approach. CloudNativePG fits teams whose workloads already live in Kubernetes and who want database lifecycle tied to the same declarative manifests as everything else. Autobase fits teams running PostgreSQL on virtual machines or bare metal, where Kubernetes is not the substrate and an Ansible inventory is the natural unit of configuration. Neither is a drop-in replacement for the other.

Maintenance, versions and the licence boundary

The release cadence visible in the material is roughly monthly: 2.9.0 in July 2026, 2.10.0 in August, 2.11.0 in September. The README states the project has been developed for over 7 years, since 2019, and that it "will remain open-source forever", with funding coming from sponsorship and support packages. For a platform you are considering running in production, that funding model matters: the open component is the Ansible automation, and the commercial component is the console and support.

The upgrade cost has two dimensions. The first is Autobase itself, which with a monthly release rhythm means you should expect to track versions rather than pin and forget. The second is PostgreSQL, and the README's claim of testing against versions 10 through 18 is the useful part here, because it means a major-version upgrade does not automatically push you off the platform. What the README does not describe is the migration path for the Autobase automation layer itself: whether roles are versioned with backward-compatible variables, and what happens to a running cluster when you update the collection. That is a question to raise with the project before a production rollout, not after.

On licensing, the repository is MIT, which is permissive and places few obligations on how you use the automation. The console editions are governed separately by their own licence terms, and the README points to the Community Edition README and the Enterprise Edition documentation rather than restating those terms. Read both before you plan a deployment that depends on console features. This is a description of what the material says, not legal advice.

Editorial conclusion

Adopt Autobase if you already run Debian, Ubuntu, CentOS Stream, Oracle Linux, Rocky Linux or AlmaLinux on x86_64 or aarch64 and you want a managed-cluster workflow without handing your data to a cloud provider. Do not adopt it if you need Kubernetes-native operators, a managed control plane, or a Windows or FreeBSD target, because none of those appear in the compatibility list. Before committing, verify three things in your own environment: that your PostgreSQL version and distribution pair appears in the daily test matrix, which console features sit behind the Enterprise licence rather than in the Community Edition, and where the Ansible collection stores cluster state and backups, since the README does not describe the backup target.

Official sources

1. autobase-tech/autobase on GitHub
2. License: MIT
3. Project website
4. README
5. Releases