What are your response times for non-critical (P2–P4) issues?

P1 critical carries an under-15-minute response SLA (24×7×365). P2 high is guaranteed at 30 minutes (24×7×365). P3 medium response is 60 minutes, and P4 low advisory queries are responded to within 90 minutes.

Do you manage High Availability solutions like MariaDB Galera Cluster?

Yes. We architect, implement and operate robust high availability for MariaDB, including MariaDB Galera Cluster and traditional replication setups, usually layered with ProxySQL or MaxScale for read/write splitting and transparent failover. Quorum is arithmetic: n = 2f + 1, so three nodes tolerate one failure and two tolerate none.

Can we run MariaDB Galera Cluster on Amazon RDS?

No. Amazon RDS lists MariaDB Galera Cluster among the MariaDB features it does not support, alongside multi-source replication and native InnoDB and Aria encryption at rest. Galera requires self-managed MariaDB, for example on EC2. We operate both the self-managed and the RDS models and will advise which suits your workload.

We're still on MariaDB 10.6: how urgent is this?

Community 10.6 reached end of life on 6 July 2026, so those binaries no longer receive updates, and RDS standard support for 10.6 ends 31 December 2026 with no paid Extended Support tier. We plan the move, build a parallel staging environment, validate against your workload and cut over without downtime, as we did taking a luxury e-commerce platform from MariaDB 10.1 to 10.6 with zero downtime.

Your MariaDB, Run by the People
Who Help Fund MariaDB

Mydbops is a Silver Sponsor of the MariaDB Foundation operating production MariaDB, Galera Cluster, MaxScale, and ProxySQL across your cloud, on-premises, RDS, or Aurora environments. You get true 24/7 coverage with an under-15-minute P1 response SLA from engineers who know wsrep_sync_wait inside out.

Scope a managed engagement →

Reviewed on Clutch

4.9 · Verified reviews

<15 minP1 response SLA

24×7×365Coverage

n = 2f+1Quorum : 3 nodes

Silver SponsorMariaDB Foundation

Certified & committed ISO 27001 ISO 9001 AWS Advanced Tier Services Partner Certified MariaDB DBAs

Brands that trust Mydbops

Why teams call us

MariaDB & Galera failure modes we actually handle

Every one of these is a documented Galera or MariaDB behaviour drawn from public practitioner reports, not a misconfiguration you should feel bad about. They are the reason a cluster that "reports healthy" can still be failing you.

🔗

Mid-SST

The node that desyncs and won't rejoin

A donor that partitions itself mid-SST can take a whole cluster down: a documented Galera behaviour, not a misconfiguration. We know which SST method your data volume warrants, and how to rebuild a node without risking the ones still serving.

🚦

Silent

Flow control that quietly stops your writes

A single slow node throttles the entire cluster. Clusters have been observed sitting flow-control-paused 100% of the time while every node still reports healthy.

👓

Peak read

Stale reads on a "healthy" cluster

Galera's certification-based replication means a write acknowledged on one node may not yet be visible on another. Most deployments behind a round-robin balancer never set wsrep_sync_wait or pin reads to the writer, and assume healthy means consistent. It does not. We configure for the guarantee your app actually needs.

🧱

Schema change

The ALTER TABLE that stops everything

Schema changes in Galera are not ordinary DDL. We plan them, run them, and own the outcome, so a migration doesn't become an outage.

📈

Over days

Memory that grows and never comes back

Certification-index growth and allocator behaviour can consume gigabytes across every node at once, until the nodes that were meant to be your redundancy fail together.

🌙

02:14 AM

The alert that lands on one engineer

Quorum lost, a node off the cluster, and the only person awake has never rebuilt a Galera member under load. One person who "knows MariaDB" is a single point of failure: the one your redundancy can't cover.

Every failure mode above is drawn from public, attributable practitioner reports. None names a client.

What we operate

Named things a MariaDB DBA would recognise: not generic benefits

Expert MariaDB operation across the whole stack: the cluster, the routing layer, backups, performance, security, and the upgrade path, cloud and on-prem.

Galera Cluster

Multi-master synchronous replication: quorum management, flow-control tuning, SST and IST strategy, node rebuild and rejoin, split-brain prevention, and the wsrep_sync_wait configuration that decides whether your reads are consistent.

quorum · flow control · SST/IST

MaxScale & ProxySQL

Read/write splitting, transparent failover, connection pooling and query routing. We run both, and we will tell you which one your workload should be on, and why.

routing · failover · pooling

Backup & recovery: mariabackup

Full and incremental backups, point-in-time recovery, and restores we have actually tested, open source, with no commercial licensing overhead.

full + incremental · restore-tested

Performance & query tuning

Percentile-based response-time analysis (P999, P99, P95), slow-query tuning, indexing strategy, and MariaDB-specific optimiser features: histograms, virtual and functional columns, invisible indexes.

P999/P99/P95 · optimiser features

Security & compliance

Access control, encryption review, audit-plugin configuration, and hardening against your compliance framework, plus proactive alarming and observability wired into the monitoring you already run.

RBAC · encryption · audit plugin

Version & upgrade management

Parallel staging environments and rolling upgrades, so a major version move happens without taking your platform offline.

parallel staging · zero-downtime cutover

Our support SLA

Strict severity response commitments: under-15-minute P1 response

Severity-based commitments under a formal Service Level Agreement: real engineers, not a ticket queue.

Severity	What it means	Response commitment	Coverage	Channel
P1 · Critical	Production down, cluster lost quorum, data unavailable or at risk	<15 mins	24×7×365	On-call engineer paged + war room (GMeet / Zoom)
P2 · High	Severe degradation, replication broken, a node down in a healthy quorum	30 mins	24×7×365	Ticket + shared Slack channel
P3 · Medium	Non-blocking issue, slow query, planned schema change	60 mins	24×7 / Business hours	Ticket + Slack
P4 · Low	Advisory, review request, documentation	90 mins	Business hours	Ticket

The under-15-minute mark is a response commitment, not a resolution commitment. We don't publish a resolution time, because no honest vendor can: resolution depends on the failure.

What happens in the first hour of a P1

T+0 Alert fires · monitoring

≤ 15 min On-call engineer responds · committed SLA

Active Diagnosis begins · you are in the channel

War room GMeet / Zoom if not contained

After Written RCA

<15 minP1 response SLA

24×7×365 coverage

800+Clients supported

6000+Servers managed

What we operate : and where our boundary sits

A three-node Galera Cluster with MaxScale routing: and the Mydbops operating boundary

This is the reference topology we run and own. Your application sits outside the boundary; everything inside it: routing, the cluster, replication, backup and audit: is ours to operate.

Quorum is arithmetic, not opinion. n = 2f + 1. Three nodes tolerate one failure; two nodes tolerate none: which is why "we have a second server" is not high availability.

This topology cannot run on Amazon RDS. AWS lists MariaDB Galera Cluster as unsupported: it needs self-managed MariaDB, for example on EC2. We operate that model, and the RDS model, and will tell you which fits.

The question every MariaDB architect is asking

What happens to Galera Cluster now?

A fair, sourced answer: because independence is the point of hiring us.

What actually happened

In February 2026, Galera clustering code was removed from the open-source MariaDB Server tree. After community objection, MariaDB plc reversed the decision and confirmed Community Server 12.3 will continue to ship Galera, stating that "now is not the time for a major change."

In July 2026, the MariaDB Foundation observed that most of the team that worked on Galera appear to be building a more enterprise-oriented solution, and that open-sourcing it is "not the current direction." Official support for Galera Cluster on MySQL ends 30 September 2026.

What it means for you, practically

Galera is supported today and your cluster is not at risk this quarter. But the long-term roadmap for open-source multi-master MariaDB is genuinely uncertain, and it is controlled by a single vendor.

Meanwhile the usual escape hatch is closed: Amazon RDS does not support MariaDB Galera Cluster, Azure is retiring its managed MariaDB product, and Google Cloud never offered one.

What we do about it

We operate your cluster on the open-source release today. We track the upstream decisions as a Foundation sponsor, rather than reading about them afterwards. And we will plan and execute a topology change (to a different HA architecture, a supported enterprise path, or a different database) on your timeline, not a vendor's.

Wherever MariaDB runs

Self-managed, RDS for MariaDB, or Aurora: covered

AWS keeps the lights on. We make sure your business runs at speed underneath them, and we operate the self-managed topologies RDS cannot run at all.

Self-managed · on-prem · EC2

Your infrastructure, our runbooks

The topologies a managed cloud cannot provide: because Galera requires self-managed MariaDB.

Galera Cluster and MaxScale/ProxySQL operations

Upgrades, patching & tested DR drills

On-prem, EC2, and hybrid topologies

Amazon RDS for MariaDB

Managed platform, expert eyes

RDS handles automated backups and host failover. It does not tune your queries, size your instances, or plan major upgrades.

Parameter-group & storage-engine tuning

Slow-query analysis, rewriting & FinOps rightsizing

CloudWatch interpretation, not just monitoring

Galera, multi-source replication & native at-rest encryption are unsupported on RDS

Aurora · MariaDB compatibility

Speed underneath the platform

The same expert bench for Aurora with MariaDB compatibility: schema and architecture on your side of the shared responsibility line.

Schema and architecture review

Query tuning against your real workload

FinOps rightsizing against actual usage

One thing worth knowing about the calendar: RDS for MariaDB has no paid Extended Support option like MySQL and PostgreSQL do. When a MariaDB version reaches end of standard support on RDS, the upgrade happens: standard support for MariaDB 10.6 ends 31 December 2026.

Map your deployment →

Version & upgrade management

The MariaDB calendar has already turned

The support model changed, and critical dates have passed. We plan the move, build a parallel staging environment, validate against your real workload, and execute the cutover without downtime.

6 Jul
2026

Passed

MariaDB 10.6 reached community end of life

If you are running community 10.6, you are running binaries that no longer receive security updates. This date has already passed: the exposure is live, not upcoming.

30 Sep
2026

Passing now

Official Galera Cluster support on MySQL ends

Part of the wider shift in how multi-master clustering is maintained. See the section above for what it does, and does not, mean for your ongoing cluster architecture.

31 Dec
2026

Upcoming

RDS standard support for MariaDB 10.6 ends

There is no paid Extended Support tier for MariaDB on RDS. When standard support ends, the upgrade happens on AWS's schedule unless you plan ahead.

LTS

Ongoing

The LTS model changed

From 12.3 onward, only the .3 release of each major version is an LTS; everything else is a rolling release supported until the next one ships. Community LTS binaries receive three years of updates rather than five, so 11.8 reaches end of life before the older 11.4.

Build vs buy

A week is 168 hours. One DBA covers about 40.

One in-house DBA ~40 of 168 hrs covered

128 hours a week with nobody on duty

Mydbops managed service 168 of 168 hrs covered

168 hrs, every week of the year

One fully-loaded DBA

$145K–$208K+/yr

US, fully loaded (Solvaria, 2026: $104,620 median wage plus ~30% benefits). In the UK, DSP itemises one business-hours DBA at £77,180 all-in.

True 24/7 cover needs

3+ people, not 1

Both published sources agree on the structural point. As Xynomix puts it: "once you've factored in round-the-clock support you're looking at over £200,000 per annum on salaries alone."

Time to a senior DBA on a P1

<15 min

A named engineer inside your cluster in minutes under a formal SLA: not a queue position behind an L1 script, and not a pager waking your one specialist again.

Figures are published, third-party industry sources (Solvaria 2026, DSP, Xynomix): cited for structure, not as Mydbops pricing. Neither source is MariaDB-specific; this arithmetic is.

Not sure which coverage model fits? Our architects map your severity profile and on-call gaps to the right model, with the numbers.

Scope a managed engagement →

Proven outcomes

Support that shows up in the metrics

A published MariaDB engagement: not borrowed proof from another database.

Luxury e-commerce · self-managed MariaDB · zero-downtime upgrade

Purple Style Labs: from MariaDB 10.1 to 10.6 with zero downtime: and $30,000 a year back

Purple Style Labs runs Pernia's Pop-Up Shop and The Stylist, India's leading luxury multi-designer platforms, with 15+ experience centres and an average order value above ₹56,000. Their checkout was slowing under peak load, replication lag was serving stale inventory to buyers, and the platform was running on MariaDB 10.1, a release years past end of life, on heavily over-provisioned hardware.

Mydbops built a parallel MariaDB 10.6 environment, migrated with no service interruption, introduced ProxySQL to route reads away from the transaction path, tuned queries using 10.6 histograms and virtual columns, deployed mariabackup for backup and recovery, and right-sized the infrastructure from four servers to one.

$30K

ARR saved

75%

Smaller server footprint

5×

Faster recovery SQL response

Zero

User impact during migration

Read the full case study →

The stability and disaster recovery have been excellent: supporting 100,000+ customers across Spain and Europe with 24/7 operations under high concurrency.

Teresa Product Owner, Hosting & Email · CDMON Scale + DR

Monthly optimization reports, query tuning, and automated backups: a steady, ongoing cadence rather than a one-off engagement.

Henry Suryawirawan VP of Engineering · Flip Ongoing cadence

For more than a year... working around the clock. The length of the relationship says as much as any single incident.

Sunil Kumar CTO · Shiprocket Long-term retainer

Their attitude towards owning up client's problems and treating them like theirs, through 20× scale, is what set them apart.

Abhishek Ravi CIO · Dream11 Ownership at 20× scale

HA cluster design

Common questions

MariaDB support, answered

We contribute. Mydbops is a Silver Sponsor of the MariaDB Foundation: a direct financial contribution to the core engineering and long-term health of MariaDB. No other independent MariaDB managed-services provider funds the upstream project. It also means we track roadmap decisions as a sponsor rather than reading about them afterwards.

Our support is governed by a formal Service Level Agreement. When a critical (P1) MariaDB issue occurs: production down, cluster lost quorum, data at risk: an on-call engineer is paged immediately and begins active resolution, day or night. Our guaranteed P1 response time is under 15 minutes, with a war room and a written RCA after the event. This is a response commitment, not a resolution time; no honest vendor can publish the latter, because it depends on the failure.

Yes. We architect, implement and operate robust HA for MariaDB, including MariaDB Galera Cluster as well as traditional replication setups, usually layered with an advanced routing tier (ProxySQL or MaxScale) for read/write splitting and transparent failover. Quorum is arithmetic: n = 2f + 1, so three nodes tolerate one failure and two tolerate none.

No. Amazon RDS lists MariaDB Galera Cluster among the MariaDB features it does not support, alongside multi-source replication and native InnoDB/Aria at-rest encryption. Galera requires self-managed MariaDB, for example on EC2. We operate both the self-managed and the RDS models, and will advise which suits your workload.

Galera is supported today and your cluster is not at risk this quarter; Community Server 12.3 continues to ship it. But the long-term roadmap for open-source multi-master MariaDB is genuinely uncertain and controlled by a single vendor, and the usual managed-cloud escape hatches are closed (RDS doesn't support it, Azure is retiring its managed MariaDB, Google Cloud never offered one). We operate your cluster on the open-source release today, track the decisions as a Foundation sponsor, and will plan and execute a topology change on your timeline if and when it is warranted.

Urgent, but manageable. Community 10.6 reached end of life on 6 July 2026: those binaries no longer receive updates, and RDS standard support for 10.6 ends 31 December 2026 with no paid Extended Support tier to fall back on. We plan the move, build a parallel staging environment, validate against your workload, and cut over without downtime. We did exactly this taking a luxury e-commerce platform from MariaDB 10.1 to 10.6 with zero downtime.

It depends on your workload, and we run both, so the advice is honest rather than whatever we happen to sell. MaxScale is MariaDB's own proxy with deep awareness of cluster state and features; ProxySQL is a widely deployed, highly configurable query router with strong rules and connection multiplexing. We will look at your routing needs, failover behaviour and connection profile and tell you which one your workload should be on, and why.

Yes, on a healthy cluster, and it is configurable. Galera uses certification-based replication, so a write acknowledged on one node may not yet be visible on another. Most deployments behind a round-robin load balancer never set wsrep_sync_wait or pin reads to the writer, and wrongly assume a healthy cluster guarantees consistent reads. It does not. We configure for the exact consistency guarantee your application needs.

A week is 168 hours; one DBA covers about 40. True 24/7 cover needs at least three people, not one: a point both published industry sources agree on (Solvaria puts a fully loaded US DBA at $145K–$208K+/yr; Xynomix estimates over £200,000 a year in salaries alone once round-the-clock cover is factored in). A managed service gives you the same round-the-clock expert bench for a fraction of standing up that rotation in-house.

P1 (critical) carries an under-15-minute response SLA (24×7×365) with on-call paging. P2 (high) is guaranteed at 30 minutes (24×7×365) via ticket and shared Slack channel. P3 (medium) response is 60 minutes, and P4 (low) advisory queries are responded to within 90 minutes during standard business coverage.

Yes. Support engagements work alongside your in-house team as a specialist bench: shared channels, on-demand troubleshooting, tuning, and incident response, while your team keeps day-to-day operational control. Managed Services, by contrast, hands us end-to-end operation of the environment. Many teams start with Support and move to Managed Services as they scale.

Onboarding is designed to be non-disruptive: a senior DBA reviews your topology, versions and pain points, agrees severity definitions and escalation paths, and stands up monitoring and a shared channel before the first incident: read-only access first. Specific engagement durations for the first 30 days are finalised and shared during scoping.

Two ways to start

Get a senior MariaDB DBA before your next 2 a.m. quorum loss

Tell us about your topology and where it hurts. We will map your severity profile to a support model with a published SLA: and be ready before the next incident.

Scope a managed engagement → Escalate a production issue

1Share your MariaDB topology & pain points

2Scoping call with a senior DBA: not a free audit, a conversation

3SLA agreed & 24/7 cover live

MariaDB Foundation Silver Sponsor · under-15-minute P1 response SLA · ISO 27001 & ISO 9001 · Certified MariaDB DBAs

Your MariaDB, Run by the PeopleWho Help Fund MariaDB

MariaDB & Galera failure modes we actually handle

The node that desyncs and won't rejoin

Flow control that quietly stops your writes

Stale reads on a "healthy" cluster

The ALTER TABLE that stops everything

Memory that grows and never comes back

The alert that lands on one engineer

Named things a MariaDB DBA would recognise: not generic benefits

Galera Cluster

MaxScale & ProxySQL

Backup & recovery: mariabackup

Performance & query tuning

Security & compliance

Version & upgrade management

Strict severity response commitments: under-15-minute P1 response

A three-node Galera Cluster with MaxScale routing: and the Mydbops operating boundary

What happens to Galera Cluster now?

What actually happened

What it means for you, practically

What we do about it

Self-managed, RDS for MariaDB, or Aurora: covered

Your infrastructure, our runbooks

Managed platform, expert eyes

Speed underneath the platform

The MariaDB calendar has already turned

MariaDB 10.6 reached community end of life

Official Galera Cluster support on MySQL ends

RDS standard support for MariaDB 10.6 ends

The LTS model changed

A week is 168 hours. One DBA covers about 40.

Support that shows up in the metrics

Purple Style Labs: from MariaDB 10.1 to 10.6 with zero downtime: and $30,000 a year back

Designing a MariaDB Galera Cluster that actually survives a node loss

When a Galera node won't rejoin: diagnosing SST and desync failures

Choosing an SST method for your data volume in MariaDB Galera

MaxScale in production: read/write splitting and transparent failover

Memory that grows and never comes back: Galera certification-index pressure

Why Mydbops is a Silver Sponsor of the MariaDB Foundation

MariaDB support, answered

Get a senior MariaDB DBA before your next 2 a.m. quorum loss

Your MariaDB, Run by the People
Who Help Fund MariaDB