Managed database services, often delivered through database-as-a-service (DBaaS) platforms, have become a pillar of modern engineering workflows. And for many stretched teams, that has been a rational response to pressure. If they need a new environment, they can simply choose a tier, wire up access, and let the provider handle patching, backups, scaling, monitoring, and failover. It removes real operational work and lets developers spend more time building.
The problem is that convenience has a way of becoming architecture. A decision made to move faster early on can harden into the operating model for systems that later become business-critical. By then, the question is not whether the service is useful, but whether the organization can keep operating when the provider, region, API, or management layer it depends on is no longer available.
Control the Control Plane
Most managed database services are designed to survive common infrastructure failures. Data is replicated across availability zones, backups are often automated, and failover may be built into the product. And while those capabilities matter and are important, they can also create a false sense of completion, as if availability inside the provider's architecture automatically translates into resilience for the customer.
Many of the actions organizations need during an incident depend on the control plane. In many DBaaS offerings, that layer is effectively a black box. The logic behind backup orchestration, security patching, scaling, failover, and network changes often sits inside proprietary systems controlled by the provider, not the customer. When that layer is degraded, the underlying database may still exist, but the customer’s ability to act becomes constrained.
AWS's own disaster recovery guidance draws this line clearly. It defines the data plane as the part delivering real-time service and the control plane as the part used to configure the environment, then advises organizations that need maximum resiliency to rely on data-plane operations during failover. So while managed recovery features are valuable day-to-day, customers still have to own their own recovery path in the event the control plane fails.
That recovery path cannot be improvised in the middle of an incident. By the time a control-plane failure exposes how dependent a team is on provider-specific tooling, the architecture has already made many of the important decisions for them.
Portability Should Be Built Long Before an Exit
Vendor lock-in is often discussed as though it begins with a contract renewal or a price increase. In practice, it usually begins much earlier, with small choices that compound over time. It may start with a provider-specific extension, or an integrated monitoring workflow, a backup process tied to the platform, or an identity model that assumes the same cloud will always be there. Each choice may be sensible on its own, but taken together, turns the database from a portable open source engine into a workload that can only operate comfortably inside one provider's ecosystem.
If the organization waits until it has a business reason to leave, whether because of cost, regulation, service quality, geopolitical constraints, or resilience concerns, it may discover that the database can move in theory but not in practice. Instead, portability needs to be treated as an architectural property, rather than a future migration project.
Regulators are starting to look at these types of dependencies more closely. The Digital Operational Resilience Act (DORA) is now applicable to EU financial entities, and says firms must maintain registers of ICT third-party arrangements so supervisors can assess dependency and risk. The EBA's technical standards on critical ICT services also emphasize control of operational risk, information security, and business continuity across the life of those arrangements. NIS2 pushes in a similar direction, including supply chain security and board-level accountability.
As a collective, the regulatory message is clear that outsourcing infrastructure does not outsource accountability. If a database supports an important service, organizations need to explain how they will continue operating when assumptions break.
A Better Default
None of this is an argument against managed services or cloud infrastructure. The cloud is still one of the most effective ways to scale systems, and managed services are a great way to reduce undifferentiated operational work. The mistake is treating managed as synonymous with resilient.
A better default starts with practical design questions:
Can the organization recover data without depending entirely on the provider's primary management interface?
Are backups independently testable and restorable?
Can failover work during a control-plane disruption?
Are encryption keys controlled at the level the data classification requires?
Can the database run on upstream open source software without proprietary hooks that make exit impractical?
For some workloads, the answer may still be a fully managed database. But the safer default is to build around upstream open source software, whether it is delivered through a managed deployment, a self-managed environment, a multi-cloud architecture, or a hybrid model. Proprietary forks and vendor-specific features can create technical cliffs over time, coupling the application to hooks that do not exist in the broader open source community. When an exit becomes necessary, that dependency can turn portability from an architectural option into a costly re-engineering project. The goal is to preserve security, sovereignty, and operational control by making sure the level of dependency matches the criticality of the workload.
Convenience has real value, and, of course, so does speed. But neither should be mistaken for operational control. The organizations that navigate outages, regulatory scrutiny, and geopolitical uncertainty most effectively will not avoid managed services entirely. Instead, they will know what they have delegated, what they have retained, and how they will operate when the easy path is no longer available.