DBaaS for PostgreSQL: How ayedo Led a European Provider to a Scalable Platform in Weeks

Database as a Service sounds simple on paper: customers click to get a PostgreSQL instance, receive backups, monitoring, and high availability – and that’s it. In reality, DBaaS is one of the most challenging platform disciplines. Not because of PostgreSQL, but because everything around it must function reliably: isolation, storage, backup strategies, observability, automation, auditability – and all this for hundreds to thousands of instances.

In this post, we illustrate through an anonymized customer project how ayedo helped a European DBaaS provider turn a strong idea into a robust product. The customer remains anonymous. The approach is reproducible.

The initial situation was typical for many teams founded from deep domain knowledge: excellent database expertise, clear market understanding, but no platform yet. The team knew exactly what they wanted to sell – a sovereign alternative to AWS RDS, Azure Database, or Google Cloud SQL – but lacked the time and team size to simultaneously build a complete production platform and manage database operations independently.

Initial Situation: A Good Idea Isn’t Enough – DBaaS Needs an Infrastructure Backbone

The customer is a young provider with around 25 employees, about 10 of whom are in platform engineering. The goal: fully managed PostgreSQL databases for European SaaS companies – including self-service provisioning, high availability, monitoring, backups, and point-in-time recovery. From the start, the offering should not seem like “a few VMs with Postgres” but like a professional service: reproducible, scalable, auditable.

This is where the first hard reality emerges: DBaaS is not “Postgres + a bit of automation.” DBaaS means that the operation of the databases itself is the software. Each instance is a product component, each automation edge a risk to availability, each backup a promise.

For a small team, this creates a classic conflict of objectives. If you build the infrastructure backbone first, months pass without revenue. If you start too quickly with manual VMs, you gain initial customers – but later pay with operational debt: non-standardized setups, unplanned downtimes, backup chaos, lack of isolation, insufficient observability.

The specific challenges were very technical, but all boiled down to one core question: How do you create a “cloud experience” with European sovereignty – without cloud hyperscalers?

Why DBaaS is Essentially a Storage and Automation Problem

In DBaaS, everything hinges on two aspects: database lifecycle management and storage design. This becomes particularly evident when scaling.

A self-service claim means that customers can create, scale, upgrade, clone, delete databases, or initiate restores without an engineer’s intervention. This requires an orchestration layer that reliably automates the entire database lifecycle – including failover, replication, and upgrades. Without solving this consistently Kubernetes-native and declaratively, you inevitably end up with a fleet of special cases.

At the same time, the backup topic explodes. With hundreds of instances, “daily backup” is no longer a job but a platform function. Point-in-time recovery with WAL archiving quickly generates enormous volumes. This data growth must be handled cost-efficiently, performantly, and geo-redundantly – ensuring that restores work reliably even under load.

Additionally, there’s multi-tenancy. A DBaaS platform thrives when many customers can use the same infrastructure. But it fails when noisy neighbors, security gaps, or insufficient isolation occur. Isolation is therefore not a “nice-to-have” but part of the product promise.

The Trigger: Time-to-Market Under Seed Funding

The founders had seed funding for 18 months. That’s not much in the platform business. If the platform builds infrastructure for six to nine months, there’s too little time left to develop, market, and scale the actual product – API, portal, billing, customer experience.

The demand was clear: the infrastructure backbone must be in place in weeks, not months. At the same time, it couldn’t be “provisional,” because these very provisional solutions become the most expensive later.

At this point, ayedo came into play – with an approach that resolves the conflict of objectives: We provide a fully managed, production-ready platform base, allowing the team to focus on the differentiating product.

ayedo’s Approach: Managed Infrastructure Backbone as an Accelerator – Without Handing Over Product Logic

We didn’t see the task as a “Kubernetes setup” but as building a scalable DBaaS backbone. This means: multi-cluster capability, separate control plane, distributed storage, observability as a platform standard, backup and recovery as default – all designed to withstand hundreds of instances.

The core of our approach consisted of three principles:

First: The control plane must be independent of the workloads. If a workload cluster has issues, it must not block the ability to deploy, observe, or recover.

Second: Storage must scale the platform, not the other way around. Block storage for database I/O and object storage for backup/archiving must be considered together, otherwise costs explode or restores become slow.

Third: Automation and auditability must be in the DNA. DBaaS without GitOps, without clear declaration, and without traceable change history is unmanageable at scale.

Infrastructure Architecture: Multi-Cluster from Day One – With Separate Management Layer

We set up several managed Kubernetes clusters in two German regions and added another cluster at a second European location. The crucial point is not “more clusters,” but blast radius and product capability. Customers should be able to choose regions. At the same time, a cluster problem must not affect the entire platform.

Additionally, we established dedicated management clusters, separate from the database workload clusters. In this management layer, the control and platform components run: GitOps controllers, central observability stack, and backup orchestration. This separation ensures the platform remains controllable – even if a workload cluster is degraded. This is invaluable in incident cases: Mixing the control plane and tooling layer with workloads creates a single point of failure in the organization.

Database Orchestration: CloudNativePG as the Heart of the Platform

DBaaS stands and falls with a reliable operator. We used CloudNativePG as a Kubernetes-native PostgreSQL operator because it can declaratively map the entire lifecycle of PostgreSQL clusters – not just provisioning, but also failover, replication, upgrades, and backup integration.

Instead of deploying “a database instance,” the platform deploys a standalone PostgreSQL cluster with a defined topology for each customer instance. For development purposes, this can be a single instance, for production a three-node HA cluster with synchronous replication, clear resource limits, and reproducible configuration. The crucial aspect: These topologies are not manual work but a standard offered by the product.

CloudNativePG also ensures that failover is not a runbook but a platform function. Node or pod failures are automatically compensated. Replication is handled consistently, and minor version upgrades can be controlled automatically. This makes operations scalable because they no longer need to be managed per instance.

Storage: Ceph as a Scalable Layer for Performance and Capacity

For DBaaS, storage is not a detail but a central differentiator. Classic cloud block storage would be expensive at this scale, and pure object storage approaches are not suitable for database volumes. At the same time, you need the advantages of object storage for backups: cost-efficient capacity, scalability, S3 compatibility.

We therefore used Ceph as a distributed storage backend and deliberately utilized two storage characteristics in one system:

For database volumes, Ceph RBD is used as replicated, high-performance block storage. This provides consistent I/O performance and remains stable even during node failures, as Ceph systemically maps replication and rebalancing.

For backups and WAL archiving, we use Ceph RGW as S3-compatible object storage. This is key to managing backup volumes: cheaper than block storage, horizontally scalable, and perfectly suited for base backups and WAL segments.

This separation – performance storage for databases, capacity storage for backups – is one of the most important platform decisions in this project. It enables cost control without sacrificing reliability or restore capability.

Backup and Point-in-Time Recovery: PITR as a Product Promise, Not an Option

In DBaaS, “backup available” is not a quality feature. The crucial question is: Can I restore reliably, quickly, and reproducibly?

We implemented point-in-time recovery through continuous WAL archiving combined with regular base backups. This allows a restore to any point within the retention period – down to the second. At the same time, backups were automatically geo-redundantly replicated to a second region to mitigate regional failures.

It was also important to us: Backup integrity must not be assumed. Therefore, automated restore tests were established to regularly verify recoverability. In practice, this is one of the most common reasons platforms fail in emergencies: backups exist, but no one has seriously tested restores.

Observability: Tenant-Ready, Scalable, Customer-Ready

A DBaaS provider needs dual observability. On one hand, the internal operations team must see the state of the entire platform: clusters, storage capacities, error rates, replication states, trends. On the other hand, customers expect self-service access to their metrics and logs – without gaining insights into other tenants.

We integrated VictoriaMetrics and VictoriaLogs as the central monitoring and logging stack. The platform advantage here lies in the native multi-tenancy capability: metrics can be stored and queried tenant-separated, without having to build separate monitoring stacks per customer. This massively reduces complexity and makes “customer dashboards” a scalable function, not a perpetual construction site.

Grafana serves as the interface – both for internal, platform-wide dashboards and for tenant-ready customer views. This allows the support team to quickly see if, for example, replication lag is increasing, connection pools are reaching limits, or storage pressure is building. Customers see exactly the signals they need to understand their application – without access to other data.

Isolation: Multi-Tenancy with Strict Separation at Network and Resource Level

Multi-tenancy in DBaaS often fails not at database operations, but at