Bring us a defined problem and leave with a defined outcome. Galera cluster architecture, major version upgrades off end-of-life releases, MaxScale and ProxySQL routing, migrations, disaster recovery, and audits. Fixed scope, named engineers, a written deliverable you keep.
.avif)
Mydbops runs project-based MariaDB consulting engagements: Galera Cluster architecture design and review, major version upgrades including moves off MariaDB 10.6 after its July 2026 end of life, MaxScale and ProxySQL routing design, cloud and on-premises migrations, disaster recovery design, and performance and security audits. Engagements are fixed-scope with a written deliverable. Mydbops is a MariaDB Foundation Silver Sponsor, ISO 27001 and ISO 9001 certified, and an AWS Advanced Tier Services Partner.
Every Mydbops consulting engagement is scoped and priced before it starts. You approve a written scope, a deliverable and a duration, and that is what you pay for. There is no open-ended retainer and no discovery phase billed by the hour.
Three shapes cover almost every engagement:
One MariaDB instance or one cluster. You receive a written report with prioritised findings, the queries and configuration behind each one, and a remediation plan.
A version upgrade, a migration, a Galera build, a MaxScale or ProxySQL rollout. Scoped against your environment, executed in your maintenance window, documented for your team.
For architecture review, second opinions and design work alongside your own engineers. A named engineer, on your problems, for the block you buy.
What is never billed: the scoping call, the proposal, or time spent understanding your environment before scope is agreed.
Choose consulting when you have a specific, project-shaped challenge with a defined outcome: a migration, a performance audit, a version upgrade, a new cluster architecture. It ends. Choose managed services when you want a long-term partnership in which our team takes proactive responsibility for your MariaDB estate around the clock. It continues.
| Consulting | Managed Services | |
|---|---|---|
| Shape | Project, with an end date | Ongoing, with a renewal date |
| You are buying | A decision, a build, or a document | Continuous operation and response |
| Typical trigger | An upgrade, a migration, an outage post-mortem, a new architecture | No in-house DBA, or one who needs cover |
| What you keep | The deliverable and the knowledge transfer | The coverage, for as long as you hold it |
| Where to go next | This page | MariaDB Managed Services → |
Many clients start with one and add the other. An audit that finds structural problems often becomes a project; a project often ends with a handover into managed services. You are never asked to decide before we have seen the environment.
If you are still on it, you are running a production database that receives no further community security fixes. The upgrade is rarely the hard part. The hard part is everything the upgrade reveals.
The optimiser behaviour that changes under load, a default character set that moves, replication that will not restart, an ORM whose read patterns were quietly depending on the old behaviour. Those are found in staging by someone who has seen them before, or in production by you.
How we run a version upgrade:
Version planning note. MariaDB shortened community LTS support from five years to three, which produces a counter-intuitive result worth checking before you choose a target: 11.8 reaches end of life on 4 June 2028, before the older 11.4 on 29 May 2029. From 12.3 onward, only the .3 release of each major series is LTS. Picking the newest release is not the same as picking the longest-supported one.
MariaDB Galera Cluster gives you synchronous multi-master replication and automatic failover. It also gives you a set of failure modes that do not exist in a standard primary-replica topology, and most Galera incidents trace back to a design decision made months earlier. These are the decisions we review, and the ones we get called about after the fact.
An even node count, or a fourth node added without thinking about quorum, is how a cluster ends up partitioned. Odd node counts, n = 2f + 1, and a garbd arbitrator where a third full node is not justified.
Which SST method, sized against your dataset and your maintenance window, and enough gcache that routine restarts resolve with an IST instead of a full SST. A donor that cannot complete an SST can take the cluster with it.
wsrep_flow_control_paused sitting near 1.0 means the cluster is running at the speed of its slowest node. That is a sizing and configuration problem, not a capacity problem, and it is visible long before it becomes an outage.
A healthy cluster does not guarantee that a read immediately after a write sees that write. Read-modify-write patterns, which most ORMs generate by default, are unsafe without wsrep_sync_wait or pinning reads to the writer. We set this explicitly.
Which DDL method, run how, and what it does to a cluster under write load. The wrong choice turns a routine schema change into a cluster-wide stall.
MaxScale or ProxySQL, in front of which nodes, with which routing rules. The proxy layer is a design decision, not a default. See the routing section below.
Why we draw it. "What exactly are you responsible for" is the question every scoping call opens with. We draw the boundary explicitly so there is no ambiguity about what an engagement covers.
What is happening to Galera, stated plainly. MariaDB plc acquired Codership, the company behind Galera, in May 2025. In late 2025 Galera dependencies began to be removed from the community server tree ahead of the 12.3 series. After public objection, MariaDB deferred the change in March 2026, in the company's own words: "now is not the time for a major change." That is a deferral, not a commitment. In July 2026 the MariaDB Foundation observed that most of the engineers who worked on Galera now appear to be building an enterprise solution, and that open-sourcing it is "not the current direction".
What that means for your cluster. Nothing breaks today. Galera in the community server remains, in the Foundation's words, "a stable and proven basis for high-availability deployments". What has changed is the planning horizon. If your high-availability strategy assumes indefinite community Galera development, that assumption now needs a review date rather than an answer.
Where Mydbops stands. We are a MariaDB Foundation Silver Sponsor. We fund the upstream project we build on, and we will design your cluster with the alternatives, and their real costs, on the table rather than off it. We will tell you when Galera is right for you, and we will tell you when it is not.
Both sit in front of your cluster and route traffic. The right answer depends on three things: your licensing position, your routing complexity, and who will operate it after we leave.
The deepest awareness of MariaDB and Galera internals: cluster-aware routing, automatic failover, binlog server, and read-write splitting that understands cluster state. It is licensed under the Business Source Licence, which converts to GPL after a delay. For some organisations that licence is a non-issue. For others it is the whole decision, and it has been the visible driver of migrations to ProxySQL since the 2025 licence change.
GPL, protocol-aware, and strong on query routing, query rewriting, connection pooling and caching rules. It is the choice when you need fine-grained rules at the query level, or when the licence has to be permissive. It is what we deployed for the Purple Style Labs engagement to resolve their read bottleneck.
What we do in an engagement: establish the licensing constraint first, because it removes one option in about half of cases; model your actual read-write split against your real query mix rather than a benchmark; design the failover behaviour and test it by causing failures, not by reading documentation; and make the proxy layer itself highly available, because a single proxy in front of a three-node cluster has simply moved the single point of failure.
The most common production MariaDB high-availability topology cannot run on RDS. AWS's own documentation lists MariaDB Galera Cluster among the features not supported by RDS for MariaDB, alongside ColumnStore, multi-source replication, the Spider, S3 and TokuDB storage engines, native InnoDB and Aria encryption at rest, and several authentication plugins. That is not an argument against RDS. It is an argument for making the choice deliberately.
If you want the operational floor handled, your topology is primary and replicas, and you do not depend on a feature on that unsupported list. The trade-off is worth naming before you commit.
If you need Galera multi-master, ColumnStore, a specific storage engine, or control over the version calendar. The RDS MariaDB release calendar has no Extended Support column, unlike MySQL and PostgreSQL, and in 2025 AWS blocked new 10.4 instances and force-upgraded the remainder outside customers' maintenance windows.
Azure is retiring its managed MariaDB service, and Google Cloud never offered one. The managed-MariaDB market is narrower than the managed-MySQL market, and that should inform a multi-year plan.
We will scope the migration either way, including away from us, and we will put the trade-off in writing before you commit.
Every engagement is scoped, executed and documented. Each links to the Mydbops work that proves it.
A written report with prioritised findings, the queries and configuration behind each one, a remediation plan, and the expected gain from each fix.
Proof: memory-leak & index-range postsParallel staging build, workload replay, regression report, cutover and rollback plan, and post-upgrade tuning on the features the new release gives you.
Proof: 10.1 → 10.6 case studyTarget design, cutover runbook, rehearsal, data validation, and a documented rollback. Cloud, on-premises, and cross-engine moves.
Proof: replication on AWS RDSReference topology, quorum and SST design, gcache sizing, a flow-control baseline, and a failure-mode runbook.
Proof: HA cluster & Galera issuesMethod selection against your dataset and window, with the restart maths written down so routine restarts resolve with an IST, not a full SST.
Proof: SST methods postsLicence assessment, routing rules against your real query mix, tested failover, and high availability for the proxy layer itself.
Proof: MaxScale & ProxySQL seriesBackup architecture on mariabackup, restore rehearsal with a measured time, and a stated recovery position your team can act on.
Proof: flashback recovery postAccess review, audit-plugin configuration, encryption position, and a compliance gap list mapped to your obligations.
Proof: MariaDB audit plugin postWe look at the environment and the problem. Not billed.
What we will do, what you receive, how long it takes, what it costs, and what is explicitly out of scope. You approve it before anything starts.
Every engagement opens with read-only access. Nothing on your system changes until we have shown you what we found and you have agreed the plan.
Implementation runs in your scheduled maintenance window, with a tested rollback path. Evenings and weekends where that is what your business requires.
You receive the written deliverable, the runbooks, and a working session with your engineers. The point is that your team can operate what we built.
We can work alongside your existing DBAs and developers, or take full ownership of the project end to end. Both are normal. Say which you want at step one.
The client operates Pernia's Pop-Up Shop, one of India's largest multi-designer luxury fashion platforms, with more than fifteen experience centres and a high average order value. Checkout was slowing under peak load, replication lag was serving stale inventory to buyers, and the platform was running on MariaDB 10.1. We built a parallel 10.6 staging environment, replayed the workload, tuned with histograms and virtual columns, added ProxySQL read routing, and right-sized the hardware.
Read full case study →The only reference that names disaster recovery and stability, covering 100,000 customers across Spain and Europe.
The Mydbops team performed our migration in just 24 hours, where others had quoted this as a 2 to 4 week project.
Mydbops supported us at 20× scale, and were clear about where their ownership began and ended.
The only reference describing an actual delivery cadence, engineering to a schedule we could plan around.
n = 2f + 1), SST and gcache sizing, flow-control baselines, stale-read handling, and the MaxScale or ProxySQL routing layer in front of the cluster, and we make the proxy layer itself highly available.Grouped by the decision each one supports.
Scoping calls are not billed and do not commit you to anything. If the answer is that you do not need us, we will say so.
