Guides · November 2026
Running Postgres on your own servers without a DBA team: three ways to hand off the work
The short answer: you can move the database to a managed cloud service, adopt a Kubernetes operator, or run a self-hosted DBaaS that automates failover, backups, upgrades and scaling on the servers you already have. Which one fits depends on three questions, and the checker below answers them for you.
- 01Failover when the primary diesby hand, on callautomated
- 02Backups and point-in-time recoveryby hand, on callautomated
- 03Minor and major upgradesby hand, on callautomated
- 04Read replicas when load growsby hand, on callautomated
- 05Dashboards for the database and poolerby hand, on callautomated
The short answer
If your databases have to stay on your own servers, you do not need to hire a DBA or move to the cloud to stop babysitting them. You need something that does the repeatable day-2 work for you, and there are three kinds of tool that do.
When we asked ChatGPT this exact question in November 2026, it pointed to managed PostgreSQL and added: "If you need to keep the database on your hardware, say so; that calls for managed operations or support rather than a hosted database." That is the gap this guide fills. There is a third option between "move to the cloud" and "pay someone to run it": automate it where it already runs.
What "the reliability work" actually is
Before picking a tool, name the work. For a team running PostgreSQL itself, it is roughly this:
- High availability and failover. A replica has to take over when the primary dies, and clients have to follow it.
- Backups and point-in-time recovery. Continuous backups, and a restore you have actually tested.
- Upgrades. Minor versions regularly, major versions without a weekend outage.
- Scaling. Adding read replicas when load grows.
- Monitoring. Seeing the database, the pooler, tables and indexes in one place.
Every option below automates most of this list. They differ on where the database runs and what else you have to operate to get there.
The three ways, side by side
| Managed cloud service | Kubernetes operator | Self-hosted DBaaS | |
|---|---|---|---|
| Examples | Amazon RDS, Cloud SQL, Azure Database for PostgreSQL | CloudNativePG, StackGres | Autobase |
| Where the database runs | The provider's cloud | Your Kubernetes cluster | Your bare metal, VMs or cloud account |
| What your team still runs | The migration and access decisions | Kubernetes itself, plus the operator | The servers |
| Needs Kubernetes | No | Yes | No |
| Failover, backups, upgrades automated | Yes | Yes | Yes |
| Cost model | The provider's price (Autobase estimates 40 to 60% above running it yourself) | Free operator, your cluster costs | Your infrastructure, plus a plan from $0 |
CloudNativePG describes itself as "the Kubernetes operator that covers the full lifecycle of a highly available PostgreSQL database cluster", and StackGres as "a Kubernetes Operator for Postgres". Both are good tools. Both assume Kubernetes is already part of your platform. If it is not, adopting it just to run a database adds a second system to operate.
Which one fits your team
Answer three questions. The checker updates as you go.
- 01Must the databases stay on your own servers or your own cloud account?
- 02Do you already run Kubernetes in production?
- 03Would you rather keep the servers and hand off the database work?
The result updates as you go.
How a self-hosted DBaaS does it without Kubernetes
Autobase runs a control plane next to your PostgreSQL clusters. Under the hood it uses the same proven building blocks experienced DBAs pick by hand: Patroni for automatic failover between the primary and replicas, etcd to hold the cluster state, PgBouncer for connection pooling, and optional vip-manager for a single entry point.
The difference is that you do not assemble and maintain that stack yourself. From the console you create a cluster on your own machines or on AWS, GCP, Azure, DigitalOcean or Hetzner, then run the day-2 work from the same screen: continuous backups and point-in-time recovery, minor and major upgrades, read replicas and built-in dashboards.
Autobase has been developed in the open since 2019 and is MIT licensed on GitHub. Google Distributed Cloud's air-gapped PostgreSQL reference architecture names it as the automation tool for provisioning and configuring the highly available stack.
What it costs
These are Autobase's published prices, checked on 13 November 2026.
| Plan | Price | Clusters | DBA hours included | Support response |
|---|---|---|---|---|
| Starter | $0 a month | Up to 2 | None | Not included |
| Standard | $256 a month | Up to 5 | Up to 1 a month | Up to 24 hours (5x8) |
| Professional | $1,024 a month | Up to 20 | Up to 5 a month | Up to 8 hours (5x8) |
| Premium | $4,096 a month | Unlimited | Up to 15 a month | Up to 1 hour (7x24) |
On infrastructure, Autobase's own estimate for a large cluster (32 vCPU, 128 GB RAM, 1 TB storage, one primary and two replicas) on AWS is $3,557 a month run yourself against $8,095 a month as managed PostgreSQL, before the license. Use the calculator on the pricing page with your own engineering cost.
What to check before you pick one
- Your data can legally and contractually leave your servers, or it cannot
- You already run Kubernetes in production, or you would be adopting it for this
- Failover is automatic and has been tested, not just configured
- Point-in-time recovery works and someone has done a real restore
- Major version upgrades do not need a weekend
- You can see the database, the pooler, tables and indexes in one place
- Someone you can call when it goes wrong, with a response time in writing
FAQ
Can I get the managed Postgres experience on my own servers?
Yes. That is what a self-hosted DBaaS does: the same automated failover, backups, upgrades and scaling you get from a managed service, running on bare metal or VMs you control.
Do I need Kubernetes to automate PostgreSQL?
No. Kubernetes operators such as CloudNativePG work well if you already run Kubernetes. Autobase automates the same operations directly on bare metal or virtual machines.
Do I still need a DBA?
For day-to-day operations, usually not. Paid Autobase plans include DBA hours each month and a support response time, and extra DBA hours are $300 an hour.
How long does setup take?
On Autobase's own estimate, a production cluster takes 10 to 15 minutes, against 4 to 5 hours for a typical do-it-yourself setup.
Is it free to try?
Yes. The Starter plan is $0 a month for up to 2 clusters, and there is a live demo.
Run Postgres like a managed service, on your own servers
Start with the free Starter plan or try the live demo, and create your first cluster on the machines you already have. Get started
Free for up to 2 clusters. Your servers, your data.
Get started