MariaDB is an open-source, commercially supported relational database management system (RDBMS) that grew out of the MySQL codebase. It aims to stay broadly compatible with MySQL while adding its own engines and features, and over time it has become a project with a distinct identity. This guide explains what MariaDB is, where it came from, how it is built, and how teams use it in production.
What Is MariaDB?
MariaDB is an SQL-based relational database server. It stores data in tables made of rows and columns, links tables through keys, and updates them through transactions that provide ACID guarantees (Atomicity, Consistency, Isolation, Durability). The server component is distributed under the GPLv2 license, which makes it free and open-source software.
MariaDB began life as a fork of MySQL. The goal was to keep MySQL's open-source spirit alive and to offer a community-developed alternative that does not depend on a single company's control. Although the two projects share the same roots, they have drifted apart over the years; today MariaDB has its own storage engines, SQL extensions, and development roadmap.
Related guides: Database types guide · What Is MySQL? · What Is PostgreSQL? · What Is Percona Server?
A Short History: Why the Fork?
Part of the team behind MySQL grew concerned about the project's open-source future after MySQL AB moved first to Sun Microsystems and then to Oracle. Led by Michael "Monty" Widenius, one of MySQL's founding developers, the MySQL codebase was forked to start MariaDB.
The name itself hints at the story. Widenius had named MySQL after his daughter "My"; MariaDB carries the name of another daughter, "Maria." The project is stewarded by two main bodies today: the MariaDB Foundation, which oversees the open-source edition, and the MariaDB Corporation, which provides commercial products and support.
Version Numbering
MariaDB's early releases tracked MySQL's version numbers to emphasize compatibility. As the projects diverged, MariaDB switched to its own numbering series (first the 10.x line, then the 11.x line). For that reason, mapping a MariaDB version directly to a same-numbered MySQL version can be misleading; when comparing features, the release notes are the right reference.
Relationship to MySQL and Compatibility
For a long time MariaDB was positioned as a drop-in replacement for MySQL. Across many releases the wire protocol, client libraries, and SQL syntax stayed largely compatible, so applications written for MySQL could often run without configuration changes. However, as the two projects evolved independently the differences have grown, so testing before a migration is now essential.
| Aspect | Notes |
|---|---|
| Origin | MariaDB is a fork of the MySQL codebase |
| Server license | MariaDB Server GPLv2; MySQL Community GPLv2, with a commercial license option as well |
| Governance | MariaDB is led by a Foundation + Corporation; MySQL is led by Oracle |
| Compatibility | High protocol/SQL compatibility across many versions; feature divergence has increased over time |
| Storage engines | MariaDB ships extra engines (Aria, MyRocks, ColumnStore, Spider, CONNECT, etc.) |
| Clustering | Galera-based synchronous multi-master replication is common with MariaDB |
Architecture and Storage Engines
One of MariaDB's most distinctive traits is its pluggable storage engine architecture. Within the same server you can choose a different storage engine per table, giving you transactional, analytical, or distributed behavior depending on the workload. The default engine is InnoDB, which provides ACID transactions and row-level locking.
| Engine | Intended use |
|---|---|
| InnoDB | Default; ACID transactions, row locking, foreign keys |
| Aria | Crash-safe successor to MyISAM; used for some system tables |
| MyISAM | Older, non-transactional engine; simple read-heavy cases |
| MyRocks | LSM-based; write-heavy workloads where disk efficiency matters |
| ColumnStore | Columnar storage for large-scale analytics/OLAP queries |
| Spider | Sharding tables across multiple servers |
| Memory | Keeps data in RAM; temporary tables needing very fast access |
Ecosystem and Tooling
MariaDB is not just a database server; together with the tools around it, it forms an ecosystem. While developing applications and operating the system, you will frequently work with the following components:
- mariadb / mysql command-line client: for running queries and administration
- MaxScale: a database proxy that provides connection routing, load balancing, and high availability
- ColumnStore: a separate engine/distribution for columnar analytical workloads
- Galera: the synchronous multi-master clustering layer
- Connector libraries: drivers/connectors for C, Java (JDBC), Python, Node.js, and other languages
- mariadb-dump / backup tools: for logical and physical backups
Most of these tools can also work with the MySQL ecosystem, but you need to watch version compatibility and the recommended driver versions. Especially for long-running production systems, it matters that your client library has been tested against the target server version.
Notable Features
MariaDB includes many parts of the modern SQL standard along with tooling that eases operations. These features are meant to cover needs beyond simple CRUD, such as analytical queries, tracking data history, and scaling. Key highlights:
- Window functions and common table expressions (CTEs) for complex analytical queries
- JSON functions for working with semi-structured data
- System-versioned (temporal) tables that automatically retain the history of rows
- Sequence objects for flexible counter/key generation
- GTID-based replication for more reliable high availability
- Various authentication and encryption plugins, plus at-rest encryption
- The MaxScale database proxy for load balancing, routing, and high availability
Installation and First Connection
MariaDB is available in Linux distribution repositories, official packages, and container images. Below is a typical Debian/Ubuntu install and a first connection with the command-line client. The client can be invoked as mariadb or, by tradition, as mysql.
# Install from the Debian / Ubuntu repository
sudo apt update
sudo apt install mariadb-server mariadb-client
# Start the service and enable it on boot
sudo systemctl enable --now mariadb
# Security wizard (root password, anonymous users, etc.)
sudo mariadb-secure-installation
# Local connection
sudo mariadb -u root -pBasic SQL Usage
The example below shows how to create a database and table, insert data, define a least-privilege user, and run a simple analytical query. The syntax will feel familiar to anyone who knows MySQL.
-- Database and table
CREATE DATABASE news_portal
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE news_portal;
CREATE TABLE articles (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
title VARCHAR(200) NOT NULL,
published_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
views INT NOT NULL DEFAULT 0
) ENGINE=InnoDB;
-- Insert data
INSERT INTO articles (title, views) VALUES
('What Is MariaDB?', 1200),
('Database Types', 800);
-- Least-privilege user for the application
CREATE USER 'app'@'%' IDENTIFIED BY 'strong-password';
GRANT SELECT, INSERT, UPDATE, DELETE ON news_portal.* TO 'app'@'%';
FLUSH PRIVILEGES;
-- Ranking with a window function
SELECT title, views,
RANK() OVER (ORDER BY views DESC) AS position
FROM articles;High Availability: Replication and Galera
MariaDB offers several ways to move beyond a single server. With classic asynchronous/semi-synchronous replication, changes on a primary are shipped to one or more replicas; this is common for spreading read load and taking backups. GTID-based (Global Transaction ID) replication makes failover and consistency across replicas easier to manage.
For higher write availability, teams use Galera Cluster. Galera provides synchronous, virtually multi-master replication: a transaction is confirmed after it passes certification on the cluster's nodes. If one node goes down, the others keep serving. A proxy such as MaxScale can be placed in front for read/write routing and automatic load balancing.
Security
MariaDB supports the security controls that enterprise environments need. Important areas include:
- Least privilege: a separate user per application with only the permissions it needs (GRANT)
- Transport security: TLS/SSL for client-server traffic
- At-rest encryption: options to encrypt table spaces and log files
- Authentication plugins: password policies and external authentication methods
- Role-based access control (roles) to simplify permission management
- An audit log plugin to track access and changes
When Should You Choose MariaDB?
MariaDB is a natural choice for teams already familiar with the MySQL ecosystem. Typical scenarios include:
- Teams wanting an open-source, community-developed alternative for existing MySQL-based applications
- OLTP workloads such as web applications and content/news management systems
- Mid-sized services that want high availability through Galera
- Teams looking for lightweight analytics via ColumnStore or write efficiency via MyRocks in the same system
For very specialized workloads, it makes sense to evaluate other systems too. PostgreSQL may fit better for a rich extension ecosystem and advanced text/geospatial features, while other solutions may suit specific compatibility needs. For a comparative view, see our database types guide.
License and Governance
MariaDB Server is distributed as free/open-source software under GPLv2; the source code is publicly available and usable under the GPL terms. Client libraries and some tools may carry different open-source licenses (for example, LGPL for connector libraries). Commercial support, consulting, and certain products come from the MariaDB Corporation, while the open-source project's governance is handled by the MariaDB Foundation.
Quick Notes for News Sites
For high-traffic news and content sites, the database layer must be set up correctly for read performance, backups, high availability, and character encoding (full Unicode and emoji support via utf8mb4). MariaDB's replication and Galera options help you scale under growing load and stay online. Proper indexing, a sensible query-caching strategy, and regular restore tests are the practices that make the biggest difference in the field.