← Database Systems Hub
Database Systems · Guide

MariaDB

MySQL fork, compatibility, Galera cluster basics.

— min read Database Systems

Theory

MariaDB: MySQL fork, compatibility, Galera cluster basics.

MariaDB is a community-developed fork of MySQL, created in 2009 when Oracle acquired MySQL. MariaDB maintains drop-in compatibility with MySQL (same SQL syntax, same connectors, same replication protocol) while adding features and maintaining fully open-source development. Most Linux distributions ship MariaDB as the default MySQL-compatible database.

Storage engines: InnoDB (same as MySQL — ACID, row-level locking, foreign keys, the default), Aria (improved MyISAM replacement, crash-safe), MyRocks (Facebook's RocksDB engine, LSM-tree-based, better write performance and compression for write-heavy workloads), Spider (sharding/federation across multiple servers via one MariaDB instance).

Galera Cluster: MariaDB's multi-master synchronous replication. All nodes are writable; writes are replicated to all nodes synchronously before committing (virtually synchronous). Any node failure is transparent — clients reconnect to another node. Requires a minimum of 3 nodes (quorum) to prevent split-brain. Used by Percona XtraDB Cluster and Galera Cluster for MySQL too.

JSON support: MariaDB added native JSON data type with JSON_VALUE(), JSON_QUERY(), JSON_TABLE() functions. JSON_TABLE() is particularly powerful — it transforms JSON arrays into relational rows, enabling SQL joins against JSON data. JSON columns are stored as LONGTEXT but validated on insert and can be indexed via generated (virtual) columns.

Temporal tables: MariaDB supports system-versioned tables — the database automatically records the full history of every row change with timestamps. Query historical data with AS OF TIMESTAMP '2024-01-01 00:00:00' to see the table state at any point in time. Useful for audit trails without manual history tables.

Replication: MariaDB uses the same binary log replication as MySQL. GTID-based replication (Global Transaction IDs) makes failover reliable — replicas track which transactions they've applied by GTID, not by log file + position. MariaDB's GTID format (0-1-100) differs from MySQL's (UUID:100), preventing direct cross-replication between MySQL and MariaDB servers.

Migration from MySQL: most MySQL applications run on MariaDB with zero code changes. Use the same mysql client, same JDBC/ODBC drivers, same ORM (SQLAlchemy, Django ORM). The mysqldump format is compatible. Key difference: MariaDB's optimizer may choose different query plans — run EXPLAIN on critical queries after migration and add/verify indexes if needed.

Architecture Diagram

Users / clients
         |
  MariaDB
         |
  Core services
         |
  Data + observability

Examples

bash 
# MariaDB
# MySQL fork, compatibility, Galera cluster basics.
# Validate in staging before production rollout.

Key Concepts

Data modelHow MariaDB structures and queries data
ConsistencyGuarantees under failure and replication
Scaling axisVertical vs horizontal growth patterns
OpsBackup, monitoring, and upgrade path

Interview Questions

What problem does MariaDB solve?

It addresses the core use case described in production architecture — map features to reliability, scale, or velocity outcomes.

Key components of MariaDB?

Identify inputs, outputs, control plane, data plane, and failure domains — interviewers want structured decomposition.

Common production pitfalls?

Misconfiguration, missing observability, no rollback path, and scaling bottlenecks under peak load.

How do you test changes safely?

Staging parity, canary/gradual rollout, automated health checks, and documented rollback.

Metrics to prove success?

Error rate, latency percentiles, throughput, cost, and toil reduction — pick one primary SLO.

Beginner vs advanced concern?

Beginners focus on setup; advanced teams focus on blast radius, security boundaries, and operability at 10× scale.

Best Practices

  • Treat MariaDB config as code with review and CI validation.
  • Define SLOs and dashboards before production cutover.
  • Document rollback and ownership for on-call.
  • Use least privilege for credentials.

Common Mistakes

  • Adopting MariaDB without measurable success criteria.
  • No staging environment mirroring production constraints.
  • Missing rollback path during incidents.
  • Undocumented on-call expectations.

Cheat Sheet

MariaDBMySQL fork, compatibility, Galera cluster basics.
SLOService level objective
RollbackRevert to last known good
CanaryLimited blast-radius rollout
RunbookIncident steps

Practical Exercises

MariaDB sandbox

Stand up MariaDB locally or in free tier; document commands and failure recovery.

Failure drill

Introduce misconfiguration; practice detection and rollback under time limit.

← MySQL

Related topics