Azure Database for PostgreSQL (Flexible Server) is the "quick start" for many teams. The problem comes later: Once load, data, and availability requirements grow, what was convenient turns into a cost and dependency structure that's hard to reverse.

The biggest exit hurdle is rarely technical – it's uncertainty: "Will we lose HA?", "How do we handle backups and PITR?", "How do we replace monitoring without Azure telemetry billing?" The answer is: You lose nothing. You regain control – and build a setup that runs just as professionally, but isn't tied to a proprietary ecosystem.

The best part: You don't have to build and operate this yourself. At OutaCloud, we set up and manage your PostgreSQL HA cluster on Proxmox – for a fraction of what you'd pay Azure for Flexible Server. Same reliability, no lock-in, predictable costs.

1) What Azure Really Charges You for Managed Postgres
2) Retail vs. Wholesale: Azure VM (Comparable) vs. Hetzner AX42
3) Service Replacement: Replace Azure Database for PostgreSQL – Without Feature Loss
4) High Availability on Proxmox: Two Patterns, Both "Enterprise-Ready"
- Option A: Patroni Cluster (Classic, Flexible, Infrastructure-Close)
- Option B: CloudNativePG (Kubernetes-Native, Very Cleanly Automatable)
5) Backups: PITR for Data + PBS for Infrastructure (This is the Combo That Works)
6) Monitoring Without Azure Tax: Grafana + Prometheus + Loki – Complete, Not "Stripped Down"
7) Migration from Azure Postgres: "Without Data Loss" is a Process, Not a Slogan
Conclusion
Ready to Migrate Your Azure Postgres?

1) What Azure Really Charges You for Managed Postgres

Azure Flexible Server isn't "one number". You're billed separately for Compute, Storage, and Backup Storage – and with HA it quickly becomes doubly relevant: Zone-redundant HA means Primary + Secondary Replica, and you pay for Compute and Storage on both sides. Plus standard network charges for egress.

This isn't "Azure-bashing" – it's pure mechanics: In practice, Managed DB costs are often underestimated because they don't just consist of "vCores" but of multiple line items that multiply with data volume and availability requirements.

2) Retail vs. Wholesale: Azure VM (Comparable) vs. Hetzner AX42

When comparing "comparable hardware resources", the Azure VM class Standard D16as v5 is a fitting reference: 16 vCPUs, 64 GB RAM. On-demand, common price lists show around $0.688 per hour – that's roughly ~$502/month for compute only (without disks, backup/traffic considerations, or database PaaS surcharges).

On the other side stands a very typical Proxmox building block: the Hetzner AX42: AMD Ryzen 7 PRO 8700GE, 64 GB DDR5 ECC, 2×512 GB NVMe (Gen4, RAID1), 1 Gbit/s, Unlimited Traffic, starting at €46/month (+ one-time setup).

This is the core of your "Compute Tax" story: Hyperscaler compute is retail pricing plus ecosystem overhead. Dedicated infrastructure is more predictable – and above all: It stays under customer ownership.

3) Service Replacement: Replace Azure Database for PostgreSQL – Without Feature Loss

When teams are attached to Azure Postgres, it's because of three things: availability, backups (including PITR), and operational comfort. We replicate exactly these three things on Proxmox – just transparently, openly, and without vendor lock-in.

The most important perspective shift: PITR is not an Azure feature. PITR is a PostgreSQL mechanism using base backups plus continuous WAL archiving. If you maintain the WAL chain properly, you can roll back to any point in time – exactly what teams value in managed services.

4) High Availability on Proxmox: Two Patterns, Both "Enterprise-Ready"

Depending on stack and team DNA, we typically build HA PostgreSQL in one of two patterns:

Option A: Patroni Cluster (Classic, Flexible, Infrastructure-Close)

Patroni is strong when you run PostgreSQL classically in VMs and need a robust failover pattern. Patroni is explicitly designed for HA Postgres and supports etcd/Consul/ZooKeeper/Kubernetes as Distributed Config Store for cluster coordination.

In practice, this means: You run 3 DB nodes (1 Primary, 2 Replicas), a small quorum/config backend, and put clean routing in front (e.g., VIP/Proxy). Failover isn't "manual at 3 AM" but automated and controllable.

Option B: CloudNativePG (Kubernetes-Native, Very Cleanly Automatable)

CloudNativePG is ideal if you're Kubernetes-first or deliberately heading that direction. CloudNativePG also supports synchronous replication models (e.g., quorum- or priority-based) and can stop writes when the required number of synchronous standbys isn't available – meaning very clear consistency/durability behavior.

Which option is "better" doesn't depend on the tool logo but on your requirements: RPO/RTO goals, write profile, operability, and how you want to handle deployments/changes day-to-day.

5) Backups: PITR for Data + PBS for Infrastructure (This is the Combo That Works)

We deliberately separate two levels:

Level 1: Database PITR (PostgreSQL-Native) At the database level, PITR is implemented via base backups and WAL archiving – this is the clean solution when you want to go "back to 12:37 before the mistake."

Level 2: Infrastructure Backups (Proxmox Backup Server) At the infrastructure level, we use Proxmox Backup Server (PBS) as a safety net: deduplicated datastores on a chunk basis reduce storage requirements and make restores fast and reliable, even across many snapshots. Additionally, PBS can encrypt backup data client-side and uses TLS for communication – important when backups go to separate locations/targets.

Result: You get operational comfort back – but as an engineering system, not a black box.

6) Monitoring Without Azure Tax: Grafana + Prometheus + Loki – Complete, Not "Stripped Down"

On Proxmox, we don't replace Azure monitoring "somehow" – we replace it completely: We run an observability stack with Prometheus (metrics), Grafana (dashboards/alerting), and Loki (logs). This covers both infrastructure signals (CPU/IO/network) and Postgres signals (replication lag, locks, connections, query load, autovacuum health) – without metered ingest/query surprises and without proprietary limits.

In short: No compromise compared to Azure comfort – just with more transparency and no lock-in.

7) Migration from Azure Postgres: "Without Data Loss" is a Process, Not a Slogan

The reliable approach is always the same: Build the target in parallel, synchronize data, run validation, then cut over in a controlled manner. How "near-zero downtime" it gets depends primarily on database size, write profile, and your tolerance for a maintenance window. What's important: We define this clearly upfront contractually/operationally – not during go-live.

Conclusion

Azure Database for PostgreSQL is convenient – but replaceable without losing reliability. With Proxmox as a platform, a clear HA pattern (Patroni or CloudNativePG), PITR-capable backup design, and observability via Grafana/Prometheus/Loki, you get exactly the operational comfort you need – just under your control and with a predictable cost structure.

If you want to leave Azure but don't want to sacrifice reliability, Service Replacement is the fastest way out of lock-in.

Also on AWS? Read our AWS RDS to PostgreSQL Guide.

Ready to Migrate Your Azure Postgres?

We take care of everything – from setup to ongoing operations. Our Managed PostgreSQL delivers exactly what you know from Azure Flexible Server: automatic failover, point-in-time recovery, monitoring, backups, updates. The difference? You pay a fraction of the cost and own your infrastructure.

We migrate your Azure PostgreSQL workloads without data loss and deliver a solid cutover plan.

Start here:

Exit Azure – Overview of our Azure migration services
Azure to Hetzner – Detailed guide on migrating to Hetzner
Calculate Your Savings – See how much you could save

Or contact us directly for a free infrastructure assessment.

Bye Bye Azure Postgres: Managed PostgreSQL on Proxmox – No Compromises

Table of Contents