MariaDB vs MySQL: The Great JSON War

After more than a decade of working with semi-structured data in relational databases, I’ve seen the full evolution of JSON support in MySQL and MariaDB. What started as a workaround has now become a robust, production-ready feature in both systems. Here’s how it unfolded — and where we stand today.

The Timeline: When JSON Finally Got Serious

2013–2014 No native JSON type in either MySQL 5.6 or MariaDB 10.0. We stored JSON as TEXT or LONGTEXT and validated it in application code. Indexing required extracting fields into separate columns. It worked — but it was fragile.

2015 – MySQL Takes the Lead MySQL 5.7.8 (October 2015) introduced a true JSON data type with:

Binary internal storage
Automatic validation on INSERT/UPDATE
Functions like JSON_EXTRACT(), JSON_CONTAINS(), JSON_ARRAY()
The -> and ->> operators (added in 8.0)

2017 – MariaDB Joins the Party MariaDB 10.2.7 (May 2017) added JSON — but as an alias for LONGTEXT with validation. Same syntax, same functions, but stored as plain text with utf8mb4_bin collation.

2018–2021 – Convergence

MySQL 8.0 (2018): ->, ->>, JSON_TABLE, multi-valued indexes, schema validation
MariaDB 10.5 (2020) & 10.6 (2021): added ->, ->>, functional indexes, JSON_TABLE By 2021, syntax and functionality were nearly identical.

2023–2025 – Maturity Both databases now support the full JSON standard. The only meaningful differences are under the hood.

Real-World Examples: Same SQL, Different Engines

Let’s use a products table:

CREATE TABLE products (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(100),
    specs JSON
);

CREATE TABLE products (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(100),
    specs JSON
);

1. INSERT – Identical Syntax, Different Storage

-- Works the same in both MySQL and MariaDB
INSERT INTO products (name, specs) VALUES 
('Laptop Pro', '{"cpu": "i7", "ram": 32, "storage": "1TB", "in_stock": true}');

-- Works the same in both MySQL and MariaDB
INSERT INTO products (name, specs) VALUES 
('Laptop Pro', '{"cpu": "i7", "ram": 32, "storage": "1TB", "in_stock": true}');

MySQL: Stores as compact binary format
MariaDB: Stores as validated text (LONGTEXT)
Validation: Both reject invalid JSON with error 3140

2. SELECT with Path Extraction

-- Extract value (quoted) or unquoted scalar
SELECT 
    name,
    specs->'$.cpu' AS cpu_quoted,
    specs->>'$.ram' AS ram_number
FROM products;

-- Extract value (quoted) or unquoted scalar
SELECT 
    name,
    specs->'$.cpu' AS cpu_quoted,
    specs->>'$.ram' AS ram_number
FROM products;

Database	specs->’$.cpu’	specs->>’$.ram’
MySQL	“i7”	32
MariaDB	“i7”	32

→ Identical output

3. Filtering and Indexing

-- Functional index on price (MariaDB 10.6+ / MySQL 8.0+)
CREATE INDEX idx_price ON products ((specs->>'$.price'));

-- Query using the index
SELECT name FROM products 
WHERE CAST(specs->>'$.price' AS DECIMAL(10,2)) < 2000;

-- Functional index on price (MariaDB 10.6+ / MySQL 8.0+)
CREATE INDEX idx_price ON products ((specs->>'$.price'));

-- Query using the index
SELECT name FROM products 
WHERE CAST(specs->>'$.price' AS DECIMAL(10,2)) < 2000;

→ Works the same in both

4. UPDATE with JSON Functions

-- Add discount and update price
UPDATE products 
SET specs = JSON_SET(
    specs,
    '$.price', 1799.99,
    '$.discount', true
)
WHERE id = 1;

-- Add discount and update price
UPDATE products 
SET specs = JSON_SET(
    specs,
    '$.price', 1799.99,
    '$.discount', true
)
WHERE id = 1;

→ Same syntax, same result

5. JSON_TABLE – Relational Unnesting

SELECT p.name, t.*
FROM products p
CROSS JOIN JSON_TABLE(
    specs,
    '$.tags[*]' COLUMNS(tag VARCHAR(50) PATH '$')
) AS t;

SELECT p.name, t.*
FROM products p
CROSS JOIN JSON_TABLE(
    specs,
    '$.tags[*]' COLUMNS(tag VARCHAR(50) PATH '$')
) AS t;

→ Available in both (MySQL 8.0+, MariaDB 10.6+)

Key Differences in 2025 (Before the Table)

Storage Format
- MySQL: Native binary — faster parsing, smaller size
- MariaDB: Text (LONGTEXT) — human-readable, larger footprint
SELECT * Visibility
- MySQL: Pretty-printed JSON by default (since 8.0.35)
- MariaDB: Always raw text — easier to copy/paste
Replication Safety
- MariaDB: 100% safe with statement-based replication
- MySQL: Risk of non-determinism in older SBR setups
Manual Editing
- MariaDB: Edit JSON directly in phpMyAdmin or CLI
- MySQL: Binary blobs — not editable without tools

Comparison Table (2025)

Feature	MySQL 8.0 / 8.4+	MariaDB 10.6 – 11.6
Physical storage	Binary (compact, fast)	Text (LONGTEXT utf8mb4_bin)
Disk usage	~30–50% smaller	Larger (text overhead)
JSON in SELECT *	Pretty-printed (8.0.35+)	Raw text (always readable)
Validation on write	Yes	Yes
-> and ->> operators	Yes	Yes
Functional indexes	Yes + multi-valued indexes	Yes (no native multi-valued)
JSON_TABLE, JSON_SCHEMA	Yes	Yes
Statement-based replication	Can break on large docs	Always safe
Manual editing in tools	No (binary)	Yes (plain text)
Performance (large datasets)	5–15× faster on JSON ops	Good, but slower

Migration Between MySQL ↔ MariaDB JSON in 2025

Dump/restore via mysqldump or mariadb-dump → 100 % compatible (both output valid text JSON)
Logical tools (Percona XtraBackup, MariaDB Backup, gh-ost) → also seamless
Only catch: if you use MySQL multi-valued indexes heavily, you lose them when going to MariaDB (but the data itself migrates fine)

Benchmarks I’ve Seen This Year (2025)

500 million rows, average document ~1.2 KB → MySQL 8.4: 18 000 JSON path lookups/sec per core → MariaDB 11.6: 4 200 JSON path lookups/sec per core → difference shrinks dramatically when you cache the queries or use generated columns

Official Roadmaps (publicly announced in 2025)

MySQL 9.0 (planned 2026–2027): JSON_OVERLAPS(), vector type integration with JSON, native JSON compression
MariaDB 11.8 / 12.0: experimental “binary JSON storage mode” (opt-in per table) – they finally want to close the performance gap

One-Sentence Verdict for Each Use Case (2025 decision matrix)

Your situation	Winner	One-liner reason
New green-field project, performance critical	MySQL 8.4	Binary format is just too fast to ignore
Existing MariaDB cluster, statement-based repl	MariaDB	Zero risk, zero changes needed
You debug directly in phpMyAdmin/HeidiSQL a lot	MariaDB	You can actually read and edit the damn thing
Heavy array handling with $. queries	MySQL	Multi-valued indexes still have no equal
Budget startup, no strong preference	Either	Difference is rarely the bottleneck anymore

Final Thoughts

In 2025, JSON support in both MySQL and MariaDB is mature, stable, and production-ready. The syntax is identical, the feature set is nearly complete, and both handle real-world workloads with ease.

Choose MySQL if you prioritize performance, work with massive JSON datasets, or use modern ORMs.
Choose MariaDB if you value debuggability, statement-based replication, or need to edit JSON by hand.

The era of “just store it in TEXT” is long gone. JSON in relational databases has grown up.

And the future? I wouldn’t be surprised to see MariaDB add an optional binary mode, or MySQL introduce a “text compatibility” flag. But for now — both are excellent. Use JSON confidently. The foundation is solid.

The only question left: what will the next data revolution look like?