MariaDB is an open-source relational database management system that began in 2009 as a community fork of MySQL and is developed under the GPL license. Among database systems, it occupies the space of a general-purpose SQL server for transactional web and business workloads, with a client protocol and SQL dialect that remain largely compatible with MySQL.
The project was started by original MySQL developers after Oracle acquired Sun Microsystems, and it is stewarded by a non-profit foundation alongside a commercial company. Over time MariaDB has diverged: it keeps the familiar server architecture and tooling, but adds its own optimizer features, storage engines, clustering and security functions that MySQL does not share.
How the MariaDB server is built
MariaDB uses a layered architecture in which a common SQL layer sits above interchangeable storage engines. The SQL layer handles connections, parsing, optimization and privileges, while each table is stored by the engine named in its definition, so one database can mix engines with different guarantees.
The default engine is InnoDB, which provides row-level locking, MVCC and crash recovery through a redo log. MariaDB maintains its own InnoDB line, and it also ships engines such as Aria for crash-safe internal temporary tables, ColumnStore for analytics and Spider for sharding across servers. The table below summarizes the engines administrators meet most often.
| Engine | Main purpose | Transactions | Typical use |
|---|---|---|---|
| InnoDB | General transactional storage | Yes, ACID | Default for application tables |
| Aria | Crash-safe non-transactional storage | No | System and temporary tables |
| MyRocks | LSM-tree storage with high compression | Yes | Write-heavy, space-sensitive data |
| ColumnStore | Columnar analytical storage | Limited | Reporting over large fact tables |
| Spider | Federation of tables across servers | Partial | Horizontal sharding |
Connections are served by a thread per connection by default, with an optional thread pool that keeps a bounded number of worker threads busy. The thread pool matters for workloads with thousands of short connections, where per-thread overhead would otherwise dominate.
MariaDB compared with MySQL and PostgreSQL
MariaDB is most often compared with MySQL, its parent, and with PostgreSQL, the other widely used open-source relational system. Compatibility with MySQL was nearly complete in early releases, but versions after 10.x diverge in replication details, JSON storage, authentication plugins and system tables, so the two should be treated as related but distinct products.
| Aspect | MariaDB | MySQL | PostgreSQL |
|---|---|---|---|
| Origin | Fork of MySQL, 2009 | Original project, now Oracle | Independent project since 1996 |
| Storage model | Pluggable engines | Pluggable, InnoDB-centered | Single heap storage with extensions |
| JSON type | Alias for LONGTEXT with checks | Native binary JSON | Native JSONB |
| Built-in clustering | Galera Cluster | Group Replication | External tools |
| Sequences | Native sequence objects | AUTO_INCREMENT only | Native sequences |
| License | GPL v2 | GPL v2 or commercial | PostgreSQL license |
Compared with lightweight embedded engines such as SQLite, MariaDB is a client-server system intended for many concurrent users. Compared with MongoDB or Redis, it enforces schemas, joins and multi-row transactions, which suits relational data with strict integrity rules.
Replication and clustering options
MariaDB offers several ways to copy data between servers, and the choice determines consistency, failover behavior and write scalability. Standard replication streams the binary log from a primary to replicas and identifies positions with global transaction IDs (GTIDs), which use a MariaDB-specific format that is not interchangeable with MySQL GTIDs.
| Mode | Commit behavior | Data loss on failover | Best fit |
|---|---|---|---|
| Asynchronous replication | Primary commits without waiting | Possible | Read scaling, reporting replicas |
| Semi-synchronous replication | Waits for one replica to receive events | Greatly reduced | Primary-replica with safer failover |
| Galera Cluster | Certification across all nodes at commit | None for certified writes | High availability, multi-primary |
| Spider sharding | Writes routed to the owning shard | Depends on shard setup | Data sets larger than one server |
Galera Cluster uses virtually synchronous replication: each transaction is certified against concurrent transactions on all nodes before it commits. It needs at least three nodes to keep quorum and is sensitive to network latency, because every commit waits for a cluster-wide round trip.
Configuring MariaDB for production
Most performance in MariaDB depends on a handful of server variables, and sensible values depend on available memory and workload. The table lists the parameters that usually matter first; the ranges are common starting points rather than fixed rules.
| Parameter | What it controls | Common starting range |
|---|---|---|
| innodb_buffer_pool_size | Cache for data and index pages | 50-75% of RAM on a dedicated server |
| innodb_log_file_size | Redo log capacity | 1-8 GB depending on write rate |
| max_connections | Concurrent client sessions | 150-1,000 with pooling in front |
| thread_handling | Thread per connection or pool | pool-of-threads for many short sessions |
| long_query_time | Slow query log threshold | 0.5-2 seconds |
Upgrades follow a long-term support release model in which selected versions receive several years of maintenance, while short-term releases bring features faster. Production systems normally stay on an LTS release and run mariadb-upgrade after each major version change to update system tables.
Common mistakes when adopting MariaDB
- Assuming a drop-in replacement for any MySQL version: modern MySQL dumps, GTID settings and authentication plugins may not transfer unchanged.
- Running Galera Cluster on two nodes, which loses quorum when either node fails or the link between them breaks.
- Leaving the buffer pool at its default size, which forces constant disk reads on a server with plenty of memory.
- Treating the JSON type as binary JSON: it is stored as text, so heavy JSON querying may need generated columns with indexes.
- Mixing non-transactional engines with InnoDB in one transaction, which prevents a clean rollback of every change.
In simple terms
MariaDB is a program that stores an organization’s data in tables and answers questions about it in the SQL language. Many websites, shops and business applications keep their customers, orders and products in it.
It started as a copy of MySQL made by the same people, so the two still look and behave much alike. Think of two related car models from the same original design: most controls are in the same place, but each now has its own engine options and extras. The key point is that MariaDB is free, widely used and close to MySQL, but not identical to it.
A practical example
An online retailer runs its catalog and order system on a single MySQL-compatible server and wants to avoid downtime when that server fails. The team builds a three-node MariaDB Galera Cluster in one data center, sets innodb_buffer_pool_size to about 60% of each node’s 64 GB of memory, and places a proxy in front of the cluster that sends writes to one node and spreads reads across all three.
Before the switch, they restore a logical dump into a test cluster and fix two stored procedures and one authentication setting that behaved differently. After migration, a planned reboot of one node no longer interrupts checkout, and the result is continuous service during maintenance with no lost orders.