Docs
Sign In
Database Architecture

Private Cloud DBaaS: Running High-Availability PostgreSQL on OpenStack

By Adrián Cameselle • Updated August 14, 2026 • 3 min read

How platform teams deliver automated PostgreSQL database-as-a-service on internal private infrastructure: automated clustering, failover mechanisms, storage layout, and multi-tenant quotas.

Table of Contents

1. Private Cloud DBaaS vs Manual Database Operations

Developers expect automated database provisioning: a single click or API call to provision an instance with connection credentials ready. When internal teams manage databases manually through tickets, operational friction increases.

Building an internal Database-as-a-Service on private infrastructure provides cloud convenience while preserving complete data residency on your own hardware.

2. High-Availability Clustering & Consensus Architecture

Production database reliability requires a robust consensus protocol to prevent split-brain scenarios during network partitioning:

  • Streaming Replication: Continuous replication streams WAL (Write-Ahead Logging) records to standby nodes.
  • Distributed Health Consensus: Distributed health monitoring continuously assesses node responsiveness and orchestrates automated failover with minimal disruption if the primary node becomes unreachable.
  • Fencing Mechanisms: Strict leader fencing prevents partitioned nodes from accepting conflicting writes.

3. Storage Layout & Cinder Volume Attachments

Database workloads require consistent I/O performance. In OpenStack architectures, Cinder storage backends should provide high-IOPS NVMe storage pools with appropriate volume QoS limits.

4. Delivering PostgreSQL via edgeContinuum Self-Service

With edgeContinuum, platform teams define curated PostgreSQL service tiers (such as Medium 10 GiB and Large 50 GiB instances). Developers instantiate databases through the console UI or Terraform, with project quotas enforcing resource boundaries automatically. For the OpenStack-specific picture, what Nova, Cinder and Neutron give you, the shape of Trove and the three routes to a database service, see the databases on OpenStack guide.

To learn more about edgeContinuum's automated database management, visit our managed PostgreSQL on OpenStack page.

Launch automated PostgreSQL DBaaS on your infrastructure

Talk to our database and infrastructure architects to see how edgeContinuum automates PostgreSQL clustering and multi-tenant quotas on OpenStack.

Book a technical call Request a free trial

Frequently asked questions

How do you achieve high availability for PostgreSQL on OpenStack?
With a primary and one or more streaming replicas, automated failover driven by a consensus mechanism, and storage placed so that a single failure cannot take the whole cluster. On OpenStack that means spreading instances across availability zones or at least across hosts using anti-affinity, backing each instance with its own Cinder volume rather than shared storage, and making sure the client-facing endpoint follows the primary automatically after a failover. The failover mechanism matters less than the discipline of actually testing it.
What is the difference between DBaaS and running PostgreSQL in a VM?
Chiefly who owns the recurring work and how reproducible the result is. In a VM, someone installs and tunes PostgreSQL, configures replication, writes backup jobs, monitors replication lag and plans upgrades, and the outcome depends on which engineer built it. DBaaS makes the database a declarative product: you request one with a version and a size, and provisioning, HA topology, failover, backups and lifecycle are handled by the platform the same way every time. The database is identical, the operating model is not.
How should Cinder volumes be laid out for a Postgres cluster?
One dedicated volume per instance, never shared between instances, on a backend whose latency profile suits write-ahead logging. Separate the data directory from backup targets so that a restore never competes with production I/O, and size for IOPS rather than only for capacity, because PostgreSQL under load is far more sensitive to latency than to raw throughput. If your backend offers multiple storage classes, put replicas on the same class as the primary so a failover does not silently change performance.
How do tenant quotas apply to managed databases?
The database counts as a managed resource inside the organization and project that owns it, so the same quotas and roles that govern clusters and virtual machines also govern databases. That has two useful effects: a team cannot quietly create more database capacity than it has been allocated, and consumption per tenant is visible per managed resource, which is what you need for chargeback. To be precise, that is usage tracking rather than billing, and the figures feed whatever accounting system you already run.
Can we run managed PostgreSQL air-gapped?
Yes. In the on-premises model the entire platform including the control plane runs inside your perimeter, so managed PostgreSQL works the same way in a fully disconnected site as in a connected one: provisioning, HA, failover and lifecycle are all local operations. Sites keep functioning through a link outage and resynchronise afterwards, which is what makes this viable for classified estates and industrial facilities where an uplink cannot be assumed.