MariaDB Cloud: The Case for Migration

Part 2 makes the case that goes beyond the dollar saving developed in Part 1. MariaDB Cloud delivers structural advantages over AWS RDS for MariaDB across four operational pillars that a typical CFO model does not capture: zero-downtime failover, white-glove dedicated support, multi-cloud portability, and security posture via the BYOA deployment model. These are not differentiators that a procurement-led RFP exercise tends to surface – they are properties of the underlying architecture and of the operational service wrapped around it.

The four pillars are introduced briefly here and developed in detail in the sections that follow. Each pillar is presented at peer depth:

• Pillar 1 – Zero-downtime failover via MaxScale: MariaDB Cloud’s active-active topology with MaxScale-mediated routing keeps applications online during node failure. AWS RDS Multi-AZ failover takes 90–120 seconds with application-side disruption – a real revenue impact for retail at peak hours and a real availability gap for any customer-facing application.
• Pillar 2 – White-glove dedicated support: MariaDB Cloud’s fractional DBA service model provides direct access to engineers who built the MariaDB engine, with proactive performance review, capacity planning, migration support, and architectural guidance. AWS Enterprise Support is a generic, database-agnostic tier; the named support engineer assigned to a customer is not, in general, a database expert.
• Pillar 3 – Multi-cloud portability: MariaDB Cloud runs natively on AWS, Azure, and GCP with the same architecture and operational model. AWS RDS by definition runs only on AWS. The strategic implications – cross-cloud disaster recovery, hyperscaler negotiation leverage, regional data residency flexibility – are real and compound over time.
• Pillar 4 – Security posture via BYOA: MariaDB Cloud BYOA on AWS, generally available June 30, 2026, deploys database compute and storage directly into the customer’s AWS account. The customer’s IAM, KMS, audit, and compliance tooling extend to the database tier. AWS RDS by architectural design places the actual database host in an AWS-managed account that the customer cannot see, audit, or apply their security tooling to.

This section presents the reference architecture that underpins the operational pillars. The architecture is intentionally described at a conceptual altitude – sufficient to understand the failover sequence and the role of each component, without reproducing implementation-level deployment details that vary across cloud providers and customer environments.

The diagram below shows the steady-state architecture with a numbered overlay (1 through 4) indicating what happens during a node failure.

Figure: MariaDB Cloud reference architecture with annotated failover sequence.

Architecture components

The reference architecture consists of nine logical components, deployed across two availability zones in a single region:

• Customer application: the application servers that connect to the database via a single DNS endpoint. The application requires no awareness of the underlying topology – connection strings, security groups, and TLS configuration are independent of which database node is currently serving any given query.
• MaxScale routing layer: MariaDB’s intelligent database proxy. MaxScale terminates client connections, performs read/write splitting (writes to the primary node, reads distributed across active nodes), runs continuous health checks against the database nodes, and orchestrates the rerouting of connections during a failure event. MaxScale is deployed redundantly across availability zones so that the routing layer itself is not a single point of failure.
• Database Node A (Active): a fully active MariaDB instance in availability zone A. Serves both read and write traffic, with the engine running continuously. State is kept current with Node B via synchronous replication.
• Database Node B (Active): a fully active MariaDB instance in availability zone B. Serves both read and write traffic. This is the architectural difference from AWS RDS Multi-AZ – in the AWS architecture, the second node is a passive standby that does not serve any traffic, only replicates state from the primary. In MariaDB Cloud’s active-active architecture, both nodes are paid for and both nodes work.
• Persistent storage layer: encrypted at rest with per-AZ replication and block-level snapshots. The storage layer is logically shared across the two database nodes for replication efficiency, with physical durability backed by multi-AZ replication of the underlying block storage.
• Synchronous replication channel: the channel by which Node A and Node B keep their state current with each other. The replication is synchronous – a write is acknowledged to the application only after it has been durably committed to both nodes, ensuring no data loss in the event of node failure.
• Control plane: the orchestration layer that manages the database lifecycle. Handles automated provisioning, patching and upgrades, failover orchestration, auto-scaling decisions, and backup scheduling. The control plane communicates with the database nodes and MaxScale instances via privileged APIs.
• Observability tier: metrics, dashboards, query and slow logs, audit logs, and alerting. Bundled in the MariaDB Cloud service rather than separately billed (the equivalent of AWS CloudWatch metrics, custom metrics, log ingestion, and Database Insights, all of which are separately metered on AWS).
• Backup tier: continuous, incremental backup with point-in-time recovery. Cross-region backup replication is available as a standard configuration option.

Why active-active matters

The single most important architectural point in this diagram is that both database nodes are active. This has both economic and operational consequences.

Economically, the customer is not paying for an idle standby. The Multi-AZ deployment in AWS RDS provides a synchronous standby instance whose vCPUs, memory, and storage are billed at full rate but which cannot serve read traffic – it exists purely to be promotable in the event of primary failure. The matched-active-vCPU sizing methodology used in Part 1’s TCO analysis accounts for this: AWS sizing of (for example) db.r6g.8xlarge Multi-AZ delivers 32 active vCPUs at full rate, while MariaDB Cloud sizing of 2 × Sky-16×128 active-active delivers 32 active vCPUs across two nodes that both serve “read” traffic.

Operationally, the consequence is more important. Because Node B is already running and already with Node A’s state, failover is not a process of starting up a standby – it is a process of removing Node A from the routing rotation. There is no warm-up time, no cache rebuild, no DNS propagation. The architecture turns failover from a multi-minute procedure into a sub-second routing change.

Failover behavior is the single most important availability characteristic of a managed database service. It is what determines whether a node failure produces a brief connection-retry blip or a multi-minute customer-facing outage. AWS RDS Multi-AZ and MariaDB Cloud differ structurally in their failover model, and the difference is the gap between an availability incident and an availability event.

Pillar 1: Zero-downtime failover via MaxScale

AWS RDS Multi-AZ failover

AWS RDS Multi-AZ failover takes 90 to 120 seconds in typical conditions, with application-side disruption throughout the window. The mechanism is as follows: the standby goes through database “crash recovery,” then, Standby is promoted to primary, the database endpoint’s DNS record is updated to point to the new primary, and the application’s connection pool gradually reestablishes connections to the new primary as the DNS update propagates and as cached connections fail.

This is not a bug – it is the architectural consequence of an active-passive topology with DNS-mediated endpoint resolution. The standby cannot start serving traffic instantly because (a) it is not actively running queries, so its buffer pools and caches are cold, and (b) the application’s clients cannot reach it until DNS resolution flips. Each of these is a multi-second process, and they happen sequentially.

During the 90- to 120-second window, the application experiences:

• Connection errors. In-flight queries and existing connections to the failed primary fail. The application’s connection pool sees a cascade of connection-refused or connection-reset errors as the existing connections die.
• Failed retries. Application-level retry logic typically retries against the cached endpoint, which still resolves to the failed primary until DNS propagation completes. These retries fail.
• Customer-visible errors. Whatever the application surfaces during a database outage – error pages, transaction failures, abandoned shopping carts – surfaces during the window.

AWS publishes a 99.95% Multi-AZ availability SLA, which works out to approximately 22 minutes of downtime per month. Multi-AZ failover events are billed against this SLA as expected behavior, not as outages.

MariaDB Cloud MaxScale failover

MariaDB Cloud’s failover sequence completes in under one second from node failure to traffic restoration on the surviving node. The mechanism is fundamentally different:

• Node A becomes unavailable due to instance failure, network partition, or maintenance event.
• MaxScale’s continuous health checks detect the failure within sub-second timeframes. MaxScale removes Node A from the routing rotation.
• All read and write traffic now flows to Node B, which was already active and serving traffic. No data loss – synchronous replication kept Node B’s state current with Node A up to the moment of failure. Application connections re-resolve to Node B’s MaxScale endpoint via the same TCP path; existing connections experience a single transient retry.
• Application sees a single transient connection retry, then resumes normal operation. No DNS change, no manual intervention, no operator paging required. The control plane begins replacing Node A in parallel with continued service from Node B.

The architectural reason this is possible is that Node B is not a standby being promoted – it is an active node already serving traffic. The failover is a routing change, not a state-machine transition. The customer’s connection pool on the application side sees one failed query (the one in flight at the moment of failure), and the next query succeeds against Node B.

Business impact at retail peak

For a retail e-commerce operator like RetailCo, the difference between 90–120 second failover and sub-second failover is real money during peak hours.

A typical mid-market e-commerce site running through a peak hour processes orders at a rate that translates to approximately $5,000 to $15,000 of revenue per minute, depending on seasonality and promotional cadence. During a flash sale, on Black Friday, or during a viral product moment, the rate can be substantially higher. A 90–120 second outage during such a window costs $7,500 to $30,000 in immediate lost transaction revenue, plus the second-order effects: abandoned carts that don’t return, customer trust damage, support ticket spikes, and elevated refund and chargeback rates from confused customers.

Multi-AZ failover events do happen. AWS commits to 99.95% Multi-AZ availability, which translates to roughly 22 minutes of allowed downtime per month. A retailer with 15 production environments experiences, in expectation, approximately 22 × 15 = 330 environment-minutes of allowed downtime per month – distributed across the fleet, but real. At even half the allowed rate, this is 11 minutes per month of failover-induced disruption fleet-wide. At RetailCo’s revenue scale, that translates to several hundred thousand dollars of annual exposure that is not modeled in the Part 1 cost stack.

MariaDB Cloud’s sub-second failover does not eliminate every form of database availability incident, but it eliminates the specific category of incident that AWS RDS Multi-AZ failover produces by design: the multi-minute application-side disruption during routine node failure or planned maintenance. The architectural difference compounds across the fleet.

Planned-maintenance windows

The same architectural difference applies to planned maintenance – patching, minor-version upgrades, instance type changes, and other operations that touch the database hosts. On AWS RDS, these operations either require a Multi-AZ failover (with the same 90–120 second customer-visible window) or extend the maintenance window beyond what the customer’s change-management process can accommodate.

On MariaDB Cloud, the active-active topology lets the operations team patch one node at a time while the other continues to serve traffic, then route traffic to the patched node and patch the second. The customer-visible impact is the same as a node failure event: a single transient retry per connection, no application-level error. This eliminates the typical customer pattern of accumulating a backlog of postponed maintenance windows because the change-management cost of each window exceeds the operational cost of waiting.

Pillar 2: White-glove dedicated support

Database support is a category where the difference between a fully managed service from a database vendor and a fully managed service from a cloud provider is operationally meaningful. The two services look superficially similar – both promise 24×7 incident response, both promise expert assistance with database operations – but the substance of what is delivered differs in ways that show up in customer outcomes. The table below captures the substantive difference at peer depth.

The fractional DBA model is the highest-value piece of the offering. A named MariaDB engineer is assigned to the customer’s account and dedicates a defined fraction of their time to ongoing MariaDB operations on a recurring basis – quarterly performance reviews, capacity planning, schema design consultation, migration support, and operational event participation. This is structurally different from reactive ticket-based support and from full-time hired DBAs (which can cost $200,000–$300,000 fully loaded for a single experienced engineer). It gives the customer ongoing access to senior database expertise at a price point meaningfully below an in-house hire.

The economic dividends are not credited to the headline TCO figures, but customer outcomes are observable: customer DBA teams typically recover 0.5 to 1.0 FTE-equivalent of capacity from RDS-specific operational tasks (RDS Proxy configuration, parameter tuning, upgrade preparation, Multi-AZ troubleshooting), database-tier incident volume drops measurably, and capacity planning accuracy improves. White-glove support matters most during major events (migrations, version upgrades, peak seasonal events), when in-house DBA capacity is constrained, and when the application is customer-facing and revenue-critical – all conditions characteristic of the customer profile this paper addresses.

Pillar 3: Multi-cloud portability

AWS RDS for MariaDB runs only on AWS. This is a definitional fact, not a limitation that AWS could relax. The service is part of the AWS service catalog, and the database hosts are EC2 instances in AWS-managed accounts. A customer running their MariaDB workloads on AWS RDS has, by adopting that service, made a decision to host that database tier on AWS for the foreseeable future.

MariaDB Cloud runs on AWS, on Microsoft Azure, and on Google Cloud Platform with the same operational model, the same architecture (active-active with MaxScale), and the same control plane experience. A customer can deploy production environments on one cloud and disaster recovery replicas on another, can move workloads between clouds in response to regulatory or commercial changes, and can avoid the kind of single-vendor concentration risk that becomes more visible during commercial renewal cycles.

What multi-cloud portability actually delivers

Multi-cloud is one of the most over-promised concepts in enterprise software. The variant that MariaDB Cloud delivers is concrete and bounded – three specific capabilities that are each economically and operationally meaningful, rather than a vague promise of “runs anywhere”:

Cross-cloud disaster recovery architectures

A customer can deploy production MariaDB Cloud on (for example) AWS in their primary region, and a disaster recovery replica on Azure in a secondary region. The replication, monitoring, and failover orchestration is handled by the same MariaDB Cloud control plane as if both deployments were on the same cloud. In the event of an AWS-region-wide failure, traffic can fail over to the Azure replica with the same architectural model that intra-cloud failover uses.

The economic value of cross-cloud DR depends on the customer’s risk tolerance and regulatory requirements. For customers in highly regulated industries (financial services, healthcare, public sector) or with explicit regulatory cross-cloud DR mandates (some EU regulators, certain APAC jurisdictions), the value is direct compliance value. For other customers, the value is in the resilience to single-cloud-provider failure modes – region-wide outages, control-plane incidents, or commercial disputes that affect service availability – that have no good answer within a single-cloud strategy.

Hyperscaler negotiation leverage

Customer renewal negotiations with hyperscalers are structurally asymmetric. The hyperscaler knows what the customer’s workloads cost to migrate elsewhere – typically a multi-quarter project at meaningful cost – and prices renewal terms accordingly. A customer whose database tier is portable across clouds has measurably more leverage in those negotiations: the implicit cost of relocating workloads is lower, and the credibility of the threat to relocate is higher.

This is not a hypothetical effect. Customers with credible multi-cloud capability report renewal terms that are 5–15% better than otherwise-similar customers without that capability, even when no actual relocation occurs. The mere capability to relocate, in negotiations with sophisticated counterparties, has commercial value.

Regional and regulatory data residency flexibility

Some customer geographies and customer industries impose data residency constraints that are tighter than the regional footprint of any single hyperscaler. The clearest example is sovereign cloud requirements in some EU member states, but similar constraints exist in regulated industries in APAC, the Middle East, and parts of Latin America. A customer whose database runtime is portable across hyperscalers can place workloads in the region or sovereign cloud that satisfies the residency requirement, rather than choosing between non-compliance and a large lift to relocate workloads.

Why this is structural, not commercial

The multi-cloud capability described above is not the result of MariaDB Cloud running parallel implementations on each hyperscaler. It is a consequence of MariaDB Cloud being built on top of MariaDB Enterprise Server – the same engine on every cloud – wrapped in the same MaxScale routing layer and the same control plane. The architecture is identical across clouds because the underlying open-source engine is identical.

AWS RDS for MariaDB cannot deliver multi-cloud portability because it is, by service definition, an AWS service. AWS could in theory build a multi-cloud version of RDS – but that would be a strategic decision contrary to AWS’s product positioning, not a roadmap item. A customer evaluating database platforms in 2026 should treat AWS RDS’s single-cloud constraint as a permanent property of the service, not a temporary limitation.

The strategic compounding effect

The three capabilities described above compound over time in a specific way. Each year a customer continues on a single-cloud database tier, the migration cost of relocating that tier elsewhere grows: more data to move, more dependencies to refactor, more institutional knowledge embedded in the cloud-specific tooling. After three to five years on AWS RDS, the realistic option to move the database tier to another cloud has effectively expired – the migration cost exceeds the strategic value of the optionality.

Each year a customer runs MariaDB Cloud, the optionality is preserved. Cross-cloud DR architectures can be added later. Workloads can be moved later. The negotiation leverage is real on each renewal cycle, not just the first one. The strategic value of preserved optionality is, in present-value terms, meaningfully positive over a three-to-five-year horizon.

Pillar 4: Security posture via BYOA

AWS BYOA – General Availability: June 30, 2026

MariaDB Cloud’s Bring-Your-Own-Account (BYOA) deployment model is generally available on AWS as of June 30, 2026. Azure GA preceded this date; Google Cloud Platform support follows. This section is written in present tense, reflecting the GA capability as of the document publication date. The GA timing is the only piece of this section that ages.

The fourth pillar of the case for migration is security posture, and it depends on a relatively new capability in the MariaDB Cloud service – the BYOA deployment model – that did not exist at the time prior versions of the cost analysis were published. This section develops the architectural difference between AWS RDS and MariaDB Cloud BYOA, the security implications for the customer’s data perimeter, and the trade-offs that an honest treatment of the model requires.

Two architectural models, side by side

The diagram below presents the two deployment models at peer depth, with equal visual weight. The left panel shows the AWS RDS architecture: the customer connects to an Elastic Network Interface (ENI) in their own VPC, but the actual database host runs in an AWS-managed account that the customer cannot see, audit, or apply their security tooling to. The right panel shows the MariaDB Cloud BYOA architecture: the database compute and storage run in the customer’s own AWS account, with the MariaDB control plane orchestrating lifecycle operations via scoped IAM roles and short-lived credentials, never accessing customer data.

Figure: Architectural comparison of the customer security perimeter in AWS RDS vs. MariaDB Cloud BYOA on AWS.

The AWS RDS architecture

AWS RDS for MariaDB uses what is sometimes called the “ENI projection” architectural model. From a networking perspective, the database appears to live in the customer’s VPC: the customer chooses subnets, security groups apply, the database has a private IP address from the customer’s CIDR range, and clients in the customer’s VPC connect to it over private networking. This is what most customers see when they look at the deployment in the AWS console.

The architectural reality is different. The Elastic Network Interface that has the customer’s IP address is, in fact, only a network interface – there is no actual compute running in the customer’s account. The ENI is a projection of network connectivity into the customer’s VPC; the host that runs the actual MariaDB engine and stores the actual data is an EC2 instance running in an AWS-managed account that is not visible to the customer. The customer cannot see the host in their EC2 console, SSH into it, collect host-level logs, or install configuration management or vulnerability scanning agents on it. AWS has full operational access; the customer has none.

This architectural model is operationally elegant for AWS – it allows them to manage the underlying compute as a service while maintaining clean tenant boundaries. But it has security and compliance implications for the customer:

• The customer’s IAM policies do not extend to the database compute. The customer cannot, for example, restrict which AWS principals can take actions on the host, because they cannot reference the host.
• The customer’s audit and compliance tooling does not extend to the database compute. CloudTrail captures API calls against the RDS service, but does not capture host-level activity. Configuration management tooling does not see the host.
• The customer’s vulnerability scanning does not reach the host. Whatever scanning AWS performs on the host is opaque to the customer; the customer cannot validate that any specific scanning regime is in place.
• The customer’s encryption key management is constrained. The customer can use a Customer-Managed Key (CMK) for storage encryption, but the actual encryption operations occur on a host the customer does not control. The KMS audit trail shows that the key was used; the trail does not show by what principal on what host.
• The customer’s logging pipeline does not include the host. Database engine logs are surfaced to CloudWatch as configured, but host-level logs (operating system audit, file system audit, network audit) are not exposed to the customer at all.

None of this is a defect in AWS RDS. It is the architectural consequence of the service’s design. A customer evaluating AWS RDS should be aware that they are accepting these constraints as a property of the service, not as a temporary limitation that AWS will remove.

The MariaDB Cloud BYOA architecture

BYOA inverts the model. The database compute and storage run in the customer’s own AWS account, in the customer’s VPC, with the customer’s IAM policies, the customer’s KMS keys, the customer’s CloudTrail and audit pipelines, and the customer’s configuration management and vulnerability scanning tooling all extending to the database tier exactly as they would to any other workload running in the customer’s account. The MariaDB Cloud control plane reaches into the customer’s account via a scoped IAM role with short-lived credentials, performs the lifecycle operations needed to manage the database (provisioning, patching, scaling, backup, monitoring, failover orchestration), and never accesses the customer’s data.

The data perimeter implications are direct and important:

• Data physically resides in the customer’s account. Database compute and storage are billable line items on the customer’s AWS bill, visible in the customer’s AWS console, and subject to the customer’s account-level controls.
• Customer IAM policies extend to the database tier. The customer can restrict which AWS principals (users, roles, services) can perform which actions on the database hosts. The MariaDB Cloud control plane operates with a scoped IAM role that is documented and that the customer can audit and adjust within the bounds required for the service to function.
• Customer KMS keys protect the data, with full lifecycle control. Encryption keys are owned by the customer’s account, can be rotated, audited, and revoked by the customer’s processes, and are used by encryption operations on hosts that the customer’s IAM controls. Key compromise scenarios are entirely within the customer’s blast radius.
• Customer audit and compliance tooling reaches the database tier. CloudTrail captures all API activity against the database hosts. Configuration management tooling can enforce baseline configuration on the hosts. Vulnerability scanning, AWS Inspector, GuardDuty, Security Hub – all of these extend to the database tier as they would to any other workload.
• Customer logging pipelines include host-level activity. Operating system audit logs, file system audit, network flow logs – all are produced on hosts in the customer’s account and flow to the customer’s logging infrastructure on whatever cadence the customer configures.

Why this matters for compliance and security posture

For a customer in a regulated industry, the architectural difference between AWS RDS and BYOA is not a nuance – it is the difference between “we can demonstrate to our auditor that the database tier is governed by our security controls” and “we depend on AWS’s controls, which we cannot directly audit.”

Specific scenarios where this difference is material:

• Data sovereignty under regulatory regimes. GDPR Article 32 and similar regulations in other jurisdictions require demonstrable customer control over data processing, including infrastructure-level controls. AWS RDS’s architecture places the data on infrastructure outside the customer’s direct control; BYOA places it inside. The compliance posture difference is direct.
• Industry-specific regulatory frameworks. Financial services regulators (OCC in the U.S., PRA/FCA in the U.K., BaFin in Germany, MAS in Singapore, and others) have evolving guidance on cloud-resident data, and the trend is toward expecting customer-controllable infrastructure at the data tier. BYOA satisfies this expectation in a way that AWS RDS structurally does not.
• Customer-controlled forensic response. In an incident response scenario where the customer’s security team needs to investigate the database tier, BYOA gives the team direct access to host-level evidence: file system snapshots, memory captures, network flow logs, OS audit. AWS RDS gives the team only what AWS chooses to expose through service APIs.
• Customer-controlled key management. Some customers operate under key management requirements that AWS-managed encryption cannot satisfy – for example, key escrow requirements, hardware security module (HSM) integration with customer-controlled HSMs, or specific cryptographic algorithm choices. BYOA puts the customer in control of these decisions.

Honest treatment of trade-offs

BYOA is not a free architectural upgrade – it shifts the shared-responsibility boundary in ways that the customer’s operations team needs to understand and explicitly accept. Two trade-offs are worth flagging:

Shared responsibility model becomes more complex

With AWS RDS, AWS owns essentially everything below the SQL layer – the operating system, the database engine, the underlying compute, the underlying storage. The customer’s responsibility boundary is clean: schema, queries, application-side connection management, and any data processed through the database. With BYOA, the customer owns the underlying compute and storage (it is in their account), MariaDB owns the database engine and operational management, and the responsibility boundaries are less crisp. Incidents that span the boundary (“Is this an infrastructure issue or a database issue?”) need clearer runbooks than RDS-style operations require.

Customers adopting BYOA should explicitly assign ownership of the gray areas: who handles host-level vulnerability remediation if the customer’s scanning tool flags an issue? Who handles AWS-side incidents that affect the database tier (e.g., AWS region issues, IAM policy changes that affect the control plane)? These questions have clear answers, but the answers need to be agreed upfront rather than discovered during an incident.

The control plane has privileged access into the customer account

BYOA is not “zero-vendor-access” architecture. The MariaDB Cloud control plane requires a scoped IAM role in the customer’s account in order to provision, patch, scale, back up, and orchestrate the database tier. The role is scoped to the minimum permissions required for these operations, the credentials are short-lived (minutes to hours, not days), and the role’s actions are captured in the customer’s CloudTrail. But the role exists, and customers should review it carefully against their security policy.

The right comparison is not “BYOA is zero-trust” versus “AWS RDS requires trust.” Both deployment models require trust in a vendor that has privileged access to the database tier. The difference is that under BYOA, the privileged access is a documented IAM role that the customer can audit and adjust, in their own account, with credential rotation under their control. Under AWS RDS, the privileged access is whatever AWS chooses to grant itself in the AWS-managed account, with no customer visibility or control. Different trust models, not “trust” versus “no trust.”

Bottom line on Pillar 4