MariaDB - What MySQL Should Have Been

Back in 2009, Oracle bought Sun Microsystems and with it, MySQL. Michael \"Monty\" Widenius, who originally created MySQL, took one look at Oracle's track record with open source projects and noped the fuck out. He forked MySQL and called it MariaDB - named after his daughter Maria, because naming databases after your kids is apparently a thing.

The fork happened because Oracle has a habit of taking good open source projects and either killing them slowly or locking all the useful features behind commercial licenses. MariaDB was Monty's middle finger to that approach.

What Makes MariaDB Different From MySQL

Storage Engines That Don't Suck: MariaDB ships with way more storage engines than MySQL because they're not trying to upsell you on every useful feature. InnoDB works fine for 99% of your use cases, but if you're drowning in writes, MyRocks might save your ass with better compression. ColumnStore is there if you need analytics without setting up a separate data warehouse.

Most people overthink the storage engine choice. Stick with InnoDB unless you have a specific problem to solve.

Features That Should Be Standard: MariaDB 11.8 LTS (released June 2025) finally added vector search, which means you can do AI similarity searches without spinning up another database. It's not going to replace your dedicated vector database for serious ML workloads, but for basic RAG applications, it'll do the job.

They also fixed the Year 2038 problem by extending TIMESTAMP support to 2106. If you're still running systems from 2025 in 2038, you have bigger problems, but at least your timestamps won't break.

Performance Reality Check

MariaDB is usually faster than MySQL in benchmarks. In real life, your bottleneck is probably your shitty queries, not the database engine. But the performance comparisons do show MariaDB consistently outperforming MySQL, especially for write-heavy workloads.

The parallel backup and restore in 11.8 is actually useful - dumping large databases used to take forever, and now it doesn't suck as much.

Galera Cluster: High Availability That Sometimes Works

MariaDB ships with Galera Cluster for multi-master replication. It works great until one node goes rogue and takes down the whole cluster. When it works, it's brilliant - synchronous replication means no data loss during failover. When it doesn't work, you'll spend 3am debugging split-brain scenarios.

Pro tip: Test your failover scenarios before you need them. Galera has opinions about network partitions that might not match yours.

Who Actually Uses This Thing

Wikipedia runs on MariaDB, which is either a great endorsement or explains why their site is slow sometimes. Google and Alibaba also use it, but they probably have custom patches and a team of DBAs to keep it running.

The Docker Hub numbers are impressive - 19 million monthly downloads - but half of those are probably developers pulling it for local testing and forgetting about it.

Cloud providers support it because they have to, not because they're excited about it. AWS RDS has it, Azure has it, GCP has MySQL only but you can run MariaDB on Compute Engine. It works fine in the cloud, just don't expect miracles.

Installing MariaDB is the same as installing MySQL - copy the commands, pray nothing breaks, and deal with whatever permissions bullshit your OS throws at you.

Installation That Actually Works

Linux Package Managers: Use your distro's package manager unless you enjoy compiling from source for no reason:

## Ubuntu/Debian - this usually works
sudo apt update && sudo apt install mariadb-server

## CentOS/RHEL - make sure you get the right repo
sudo dnf install mariadb-server mariadb

## Run this to not get pwned immediately
sudo mysql_secure_installation

Docker for Development: The official MariaDB container is probably the easiest way to get started without fucking up your local system:

docker run --name some-mariadb -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mariadb:11.8

Production Configuration Reality

The default config works fine for development. Production needs tuning unless you enjoy watching your database struggle under load.

Memory Settings That Matter: Give InnoDB most of your RAM, but not all of it because the OS needs some too:

## For a 16GB server
innodb_buffer_pool_size = 12G
innodb_log_file_size = 1G
max_connections = 200  # Not 500, you don't need that many

Storage Engines: InnoDB handles 99% of use cases. MyRocks is good if you're drowning in writes. Everything else is for edge cases that probably don't apply to you.

Migration Horror Stories

From MySQL: It usually just works. Your app connects to MariaDB with the same connection string and everything keeps running. Until it doesn't, and you discover some edge case that breaks in weird ways.

From Oracle: MariaDB's Oracle compatibility is about 60% there. Good enough for simple stuff, nightmare fuel for complex stored procedures. Budget extra time for debugging weird PL/SQL incompatibilities.

From PostgreSQL: Don't. The syntax differences will make you hate everything. Just rewrite your queries.

What Actually Breaks in Production

Galera Split-Brain: Your beautiful 3-node Galera cluster will eventually decide it's actually 3 separate single-node clusters. Usually happens during network hiccups at 3am.

Memory Exhaustion: MariaDB will happily consume all your RAM if you let it. Monitor `innodb_buffer_pool_size` vs actual memory usage or prepare for OOM kills.

Replication Lag: Master-slave replication randomly stops working. The error message will be cryptic. Check the binlog position and pray it's just a transient network issue.

Connection Limits: You'll hit `max_connections` before you expect to. Connection pooling helps, but you'll still get that "too many connections" error at the worst possible time.

Tools That Don't Suck

phpMyAdmin: Still the easiest way to browse your data, even if it looks like it's from 2005.

DBeaver: Actually good database client that won't make you want to quit programming.

Percona Toolkit: Essential for anyone running MySQL/MariaDB in production. `pt-query-digest` alone will save your ass.

Monitoring That Actually Helps

Don't rely on just `SHOW STATUS`. Set up proper monitoring:

• Slow Query Log: Enable it, analyze it with `pt-query-digest`
• Connection Count: Watch for connection leaks
• InnoDB Metrics: Buffer pool hit ratio, log waits, deadlocks
• Replication Lag: If you're using slaves

Grafana + Prometheus works fine. So does Datadog if you have money to burn.

Cloud Deployment Reality

AWS RDS: Works fine, expensive, you can't tune everything you want to
Google Cloud SQL: MySQL only, but MariaDB runs on Compute Engine
Azure Database: Same story, different cloud provider

All the managed services are decent but charge premium prices for the convenience of not having to manage backups and failover yourself. Worth it if your time is expensive.