MySQL and MariaDB: the classic LAMP stack honestly assessed for 2026

What are MySQL and MariaDB?

MySQL is the classic relational database of the LAMP stack (Linux, Apache, MySQL, PHP), developed since 1995 under GPL-2. Since 2010 the project belongs to Oracle, which raises concerns among some users about long-term OSS direction. MariaDB is the open-source fork of MySQL, started in 2009 by Michael "Monty" Widenius (the original MySQL inventor) as a response to the Oracle acquisition. MariaDB Foundation stands behind the project.

In May 2026, MySQL 8.4 LTS is current (LTS until April 2032), MariaDB 11.4 LTS is the stable long-term variant (support until May 2029). Both databases remain available as default RDBMS in most Linux distros -- on Debian and Ubuntu, MariaDB has been the default for years.

Functionally both systems are close relatives but diverge on JSON support, window functions, CTEs, storage engines, and security. MariaDB has its own spatial extension, ColumnStore (a columnar engine for analytics), Galera Cluster for multi-master, and Oracle compatibility mode. MySQL offers more mature JSON-Path and JSON-Schema validation, stronger Group Replication and InnoDB Cluster, and MySQL HeatWave as a cloud analytics solution. Anyone building a new stack in 2026 should check the specific differences -- the choice is not trivial.

License model: MySQL Community Edition remains GPL-2 with the classic dual-license strategy by Oracle (Enterprise Edition paid). MariaDB is GPL-2 for the server core and uses the Business Source License (BSL) for some enterprise modules with 4-year conversion to GPL-2. For pure SME self-use of either server, there are no license problems.

Why it matters

MySQL and MariaDB are in production at hundreds of thousands of Swiss SME systems: PHP shops, WordPress sites, embedded CMS, applications from the 2010-2018 bull-market phase. Anyone with an existing application has a real question -- stay or migrate.

Three arguments to stay. First: stability. A running MySQL application with 5-10 years of production history has shown its worst-case behaviour. Data corruption via bugs is extremely rare, backup routines are established. Second: tooling maturity. phpMyAdmin, MySQL Workbench, Percona Toolkit, and monitoring solutions have matured over 20+ years -- the operations learning curve is flat. Third: hosting availability. Every shared hoster offers MySQL/MariaDB, every cloud provider has managed services (RDS, Cloud SQL, Azure Database for MySQL).

Three arguments to migrate to Postgres. First: feature depth. JSON, window functions, CTEs, pgvector, PostGIS are more mature in Postgres. Whoever starts a 2026 greenfield project gets more for the same money. Second: license clarity. Postgres license (MIT-like) is more permissive than GPL-2 / BSL. Third: migration path to modern systems (Cockroach, Supabase, Neon) is easier with Postgres.

For the Swiss fiduciary market we recommend in 2026 the following heuristic: existing MySQL/MariaDB applications stay on MySQL/MariaDB, possibly with MariaDB migration (drop-in replacement) instead of Oracle MySQL. New applications with OLTP focus start on PostgreSQL. Hybrids are possible -- one main DB per application, no DB zoo. Data residency works for both systems on Hetzner Falkenstein.

How it works

MySQL and MariaDB are classic multi-process servers with threaded connection handling. The mysqld process accepts connections; each connection gets a worker thread. Storage engine InnoDB has been the default since MySQL 5.5 (2010) and delivers ACID transactions, foreign keys, and row-level locking. Older MyISAM tables should not have any production use in 2026.

A minimal production setup looks like this:

CREATE DATABASE fiduciary CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE fiduciary;

CREATE TABLE clients ( id BIGINT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(255) NOT NULL, metadata JSON, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_name (name), INDEX idx_metadata ((CAST(metadata->>"$.industry" AS CHAR(100)))) );

Charset utf8mb4 is mandatory for correct emoji and Unicode handling -- the old "utf8" is not real UTF-8 and has caused many problems in legacy systems. For new schemas in 2026: utf8mb4 as default, utf8mb4_0900_ai_ci (MySQL) or utf8mb4_uca1400_ai_ci (MariaDB) as collation.

Replication runs via the binary log: primary writes every write operation to binlog, replica reads and replicates. Asynchronous, semi-synchronous, or synchronous (GTID-based). Galera Cluster (MariaDB) and Group Replication (MySQL) offer multi-master setups -- with increased complexity and some restrictions for DDL and locks.

Backup standard: nightly mysqldump for small databases (< 20 GB), mariabackup / xtrabackup for larger ones (online backup without lock). Plus binary-log archiving for PITR. Recovery: replay mysqldump, then apply binary logs to the desired point in time. A 50 GB database is back in 30-60 minutes -- slower than Postgres pg_basebackup but proven.

Monitoring via mysqld_exporter for Prometheus, Percona Monitoring Plugins for Zabbix/Grafana. Key metrics: InnoDB buffer pool hit ratio (> 95 percent target), Threads_running, slow query log, replication lag.

MySQL/MariaDB to production in 5 steps

1. 01Provision a Hetzner server, start MariaDB 11 (or MySQL 8.4) as Docker container, tune my.cnf with innodb_buffer_pool_size at about 60 percent of RAM.
2. 02Create schema with utf8mb4 and InnoDB as default, set foreign keys and indexes consistently, ban MyISAM tables.
3. 03Backup strategy: nightly mariabackup to a separate storage box, continuous binary-log archiving, 30-day daily retention.
4. 04Wire monitoring: mysqld_exporter for Prometheus, slow query log with long_query_time=1, Grafana dashboard with buffer pool hit ratio and Threads_running.
5. 05Quarterly disaster-recovery test: replay backup on a separate server, PITR with binary logs to a point 1 hour ago, update the runbook.

When to use MySQL or MariaDB

The right choice when (a) an existing system runs stably on MySQL/MariaDB, (b) a PHP-based application with MySQL hosting should be deployed, or (c) the team has many years of MySQL experience and does not need Postgres-specific features.

Concrete scenarios: WordPress sites with high traffic, classic LAMP applications, Magento or PrestaShop shops, old Symfony/Laravel apps with established MySQL bindings, shared hosting setups in Switzerland where MySQL is the only available DB.

MariaDB as a drop-in replacement for Oracle MySQL is attractive in 2026: switch without application code changes, default in Debian/Ubuntu, long-term OSS-oriented, Galera Cluster available. Whoever stays on MySQL should understand the Oracle license topics and the Enterprise vs. Community model -- there is no royalty obligation for Community Edition under GPL-2, but Oracle controls the roadmap.

When not to use

For a greenfield project in May 2026, PostgreSQL is the better default choice -- stronger JSON functions, native vector search via pgvector, broader extensions ecosystem, cleaner license. MySQL/MariaDB are not a mistake, but they are no longer the obviously best choice in 2026 that they were in 2015.

For highly complex analytics queries with window functions, recursive CTEs, and JSON aggregations, MySQL is weaker than Postgres -- reports become harder to write. Whoever has reporting-heavy workloads plans either Postgres or a columnar DB like ClickHouse / DuckDB alongside.

For AI RAG pipelines with vector search, MySQL/MariaDB without a native vector extension is unsuitable -- you need an additional vector DB (Qdrant, Weaviate, Pinecone). Postgres with pgvector saves this second server.

For multi-region synchronicity with global consistency, MySQL Group Replication is possible but operationally complex. CockroachDB is the better choice when real multi-region requirements exist.

For SaaS products that may later want to switch to cloud-hyperscaler database services (Aurora, Cloud SQL), Postgres compatibility is a bigger advantage than MySQL compatibility -- the whole CockroachDB and Supabase world builds on the Postgres wire protocol, not on MySQL.

Trade-offs

FAQ

Related topics

Sources

1. MySQL 8.4 LTS Release Notes · 2026-05
2. MariaDB 11.4 LTS Release Notes · 2026-05
3. MariaDB Licensing FAQ (BSL, GPL-2) · 2026-04
4. MySQL vs MariaDB feature comparison · 2026-04