Databases on OpenStack: DBaaS architecture, Trove and the alternatives

OpenStack hands you instances, volumes and networks. A database service is everything between those primitives and a developer typing "give me a PostgreSQL 16 with failover". This is what sits in that gap, why Trove rarely fills it, and the three routes teams actually take. There is a fourth: edgeContinuum delivers managed PostgreSQL on the infrastructure you already operate, with none of this to build.

1. What OpenStack gives you, and what it does not

Every ingredient for a database is already in an OpenStack deployment. Nova gives instances with predictable flavors, Cinder gives block volumes with volume types you can map to real storage tiers, Neutron gives isolated networks and security groups, Keystone gives per-project identity, and object storage gives somewhere to put write-ahead logs.

What is missing is everything that makes those ingredients a service: a catalog entry a developer can order, a topology decision made once and applied identically every time, replication configured and verified, failover that promotes a standby without a human, backups that run and get restored as a test, minor patches applied on a schedule, major upgrades planned, and per-tenant limits so one team cannot fill the array.

The distance between "PostgreSQL is easy to install" and "PostgreSQL is a product our teams order" is that list. It is also why the request "we need a database" is answered in weeks on most private clouds and in seconds on a public one.

2. Trove: what it is and why teams hesitate

Trove is OpenStack's own database-as-a-service project, and it is still developed: it ships in current OpenStack releases and PostgreSQL is one of its supported datastores. The architecture is distinctive. A Trove instance is a Nova instance booted from a Trove guest image with a guest agent inside it, and since the Victoria release a single guest image serves every datastore, with the database itself running as a container inside that instance.

Three things make teams hesitate, and none of them is a criticism of the code:

• You own the guest images. The project's own production guidance is to build and maintain your own images so they meet your security standards, which means an image pipeline per datastore version, rebuilt for every CVE, forever.
• The guest agent is a second control path. Every database instance runs an agent that takes instructions over the message bus. That is one more component to secure, upgrade and debug inside every instance you run, and it does not exist in the other routes.
• Vendor support thinned out. Trove was dropped from Red Hat's OpenStack distribution years ago, so on many enterprise deployments it is not a supported service at all, and the operator community around it is small compared with Nova or Neutron.

The result is that Trove is technically available and organizationally rare. edgeContinuum does not use Trove: managed PostgreSQL is delivered without a guest agent inside the database instance and without a datastore image pipeline for you to own.

3. The three routes to PostgreSQL as a service

Trove

Databases become first-class OpenStack resources with their own API, quotas and CLI, which is genuinely coherent when your operators want everything inside one cloud API. The cost is the guest image pipeline, the guest agent and a thin support ecosystem.

Virtual machines plus your own automation

Instances from Nova, volumes from Cinder, and Patroni with etcd or Consul for leader election, pgBackRest or WAL-G for backups, and Ansible to tie it together. This is the most common answer and it works well, because Patroni is excellent. What stays yours is the whole surface: templates, failover testing, backup verification, monitoring, minor patching, major upgrades, and the fact that every instance is slightly different from the last one somebody built.

An operator on Kubernetes, on top of OpenStack

If you already run Kubernetes on OpenStack, a PostgreSQL operator turns databases into custom resources reconciled by a controller, which is the cleanest declarative model of the three. It also stacks two platforms: the database's availability now depends on the cluster's, storage arrives through Cinder CSI rather than directly, and someone has to own both layers. For a team that already operates Kubernetes seriously, this is the strongest self-built route.

4. Cinder, availability zones and the storage decisions

Database performance on OpenStack is mostly a storage question, and the defaults are rarely the right answer.

• Volume type per tier, not one default. Map Cinder volume types to real backends and pick deliberately per database. A default class quietly sends a transactional workload onto the cheapest pool.
• Size for IOPS, not only capacity. PostgreSQL under load is latency-sensitive, and write-ahead logging punishes high-latency storage far more than a capacity graph suggests.
• One volume per instance, never shared. Each member of a cluster gets its own volume, so a storage failure cannot take the primary and its standby together.
• Spread across availability zones, or at least across hosts with anti-affinity, so a single hypervisor failure cannot take a quorum with it.
• Keep backup targets off the data path. Archive write-ahead logs to object storage rather than to the same volume, so a restore never competes with production I/O.

The high-availability topology itself, quorum, synchronous versus asynchronous standbys and split-brain avoidance, is worked through in the private cloud PostgreSQL DBaaS architecture guide.

5. Backups are not snapshots

A Cinder snapshot of a running database volume is a crash-consistent image, and PostgreSQL will usually recover from it. Usually is not a backup strategy. A database backup regime has three properties a snapshot does not: continuous write-ahead log archiving so you can recover to a point in time rather than to whenever the snapshot ran, retention that is independent of the volume's lifecycle so deleting an instance does not delete its history, and a restore that has actually been performed.

The last one is the one that fails in production. An untested restore path is an assumption, and the day it matters is a bad day to test it. Whichever route you take, schedule restores into a scratch project as a routine job, not as an incident.

6. Tenancy: whose database is it

On a single-team OpenStack, none of this matters. With several teams, or clients you serve, four questions arrive at once: which project owns the instance and its volumes, who can see the credentials, what limits stop one team from consuming the array, and how consumption gets reported per tenant.

OpenStack projects answer the first two adequately and the second two only partly. Project quotas bound instances, volumes and gigabytes, which is a proxy for database consumption rather than a measure of it, and nothing at that layer knows that six instances and their volumes together are "three PostgreSQL clusters belonging to the data team". That gap, and the organizations and roles that close it, is the subject of the users, projects and quotas guide.

7. Version lifecycle, the job nobody schedules

PostgreSQL ships a new major version every year and supports each one for five, with minor releases roughly quarterly. That produces two very different jobs. Minor patching is mechanical, restart-only, and easy to postpone until a CVE forces a rushed window across every instance at once. Major upgrades are a project each time: a choice between dump and restore, an in-place upgrade, or logical replication into a new cluster with a controlled cutover, plus extension compatibility and application testing.

On a self-built estate, both jobs scale with instance count and land on whoever built the templates. This is the work that quietly consumes a DBA's year, and it is the clearest argument for making the database a product rather than a build.

8. Skip the build: PostgreSQL as a catalog product

edgeContinuum delivers PostgreSQL as a catalog product on the OpenStack you already operate. A team asks for a database with a version and a size, inside the quota its project carries, and the platform provisions it, configures high-availability clustering, handles failover, runs backups and drives version lifecycle from declarative desired state. Instances are scoped to projects and organizations, so consumption is attributable per tenant, and the same platform behaves identically from SaaS control plane to a fully air-gapped deployment.

No guest agent inside your database instances, no datastore image pipeline, no Trove, and nothing forked in the OpenStack underneath: it keeps using standard Nova, Cinder and Neutron APIs, and your operators keep their existing tooling. See managed PostgreSQL on your own infrastructure for what the service does, or the OpenStack management platform page for the layer it belongs to.

Where to start: request a free trial and create a highly available PostgreSQL instance against a lab OpenStack in minutes. If you have databases running today, bring them to the call below and our engineers will work the migration path with you.

Frequently asked questions