MariaDB 11.7: The Fork That Keeps Its Own Path

Updated: 2026-07-12

MariaDB 11.7 (November 2024) is a release that consolidates the fork’s independent direction from MySQL, according to the official MariaDB announcement^[1]. Three areas receive primary attention: natively integrated vector search, without additional extensions; substantial improvements to JSON support; and query engine optimisations that translate to 5-15% performance improvements in benchmarks vs 11.5. It is the first release in a while that has made me stop and genuinely weigh whether the upgrade is worth it. For teams that chose MariaDB years ago and wonder whether to stay or migrate, this version clarifies the argument.

Key takeaways

• Native vector search with HNSW index: MariaDB 11.7 supports similarity search without external extensions, while MySQL only offers it through HeatWave.

• JSON_OBJECT_AGG and JSON path improvements bring MariaDB closer to functional parity with PostgreSQL JSONB for many use cases.

• The divergence from MySQL keeps growing: Galera multi-master vs Group Replication, real pluggable storage vs InnoDB-centred, community licence vs Oracle-backed.

• MariaDB is not always better than PostgreSQL or MySQL: each database has its strengths and optimal use cases.

• Application compatibility with MySQL remains high for standard CRUD operations; divergence appears in advanced features.

Vector search: the most relevant new feature

The vector search integrated in MariaDB 11.7 is the change most affecting the decision map for teams already running MariaDB in production who are evaluating where to store embeddings for RAG applications or semantic search.

The syntax is extended standard SQL:

-- Create table with vector column
CREATE TABLE documents (
    id INT PRIMARY KEY AUTO_INCREMENT,
    title VARCHAR(255),
    content TEXT,
    embedding VECTOR(384)
);

-- Create HNSW index for efficient search
ALTER TABLE documents ADD VECTOR INDEX idx_embedding (embedding)
    WITH (M=16, EF_CONSTRUCTION=200);

-- Insert with embedding
INSERT INTO documents (title, content, embedding)
VALUES ('Introduction to eBPF',
        'eBPF allows executing code in the kernel...',
        VEC_FromText('[0.12, 0.34, -0.56, ...]'));

-- Similarity search
SELECT id, title,
       VEC_DISTANCE_EUCLIDEAN(embedding, VEC_FromText('[...]')) AS distance
FROM documents
ORDER BY distance
LIMIT 10;

The HNSW (Hierarchical Navigable Small World) index is the same algorithm used by pgvector, documented in its official repository^[2], and most specialised vector databases. The official MariaDB Vector project page^[3] details the VECTOR(N) type and the available distance functions. For teams already running MariaDB who want to add semantic search without adding a separate vector database, this change eliminates an infrastructure component.

Current limitations, put plainly: MariaDB 11.7’s vector search is functional but still immature compared to pgvector in terms of index options, available distance metrics, and performance at very high cardinality. For serious production, evaluate whether performance is sufficient for your specific scale before committing.

JSON improvements

The most useful addition in 11.7 is JSON_OBJECT_AGG, which aggregates rows into a JSON object:

SELECT user_id,
       JSON_OBJECT_AGG(key, value) AS preferences
FROM user_configuration
GROUP BY user_id;

-- Result: {"theme": "dark", "language": "en", "notifications": "1"}

Along with improvements to JSON path expressions and faster JSON operations, MariaDB 11.7 narrows the gap with PostgreSQL JSONB for use cases storing semi-structured data in JSON fields. It does not reach full parity: PostgreSQL has a richer JSON function ecosystem and more flexible GIN indexes on JSONB fields, but the practical difference shrinks for most common uses.

Query engine optimisations

The optimiser improvements in 11.7 are most noticeable in:

• Multi-table joins: better cardinality estimation in joins with updated column statistics.

• Correlated subqueries: the optimiser is better at spotting when a correlated subquery can be turned into a join, cutting down on repeated scans.

• Covering indexes: improved use of covering indexes to avoid hitting the base table.

The MariaDB project’s own benchmarks show 5-15% improvements over 11.5 on read-intensive workloads. Improvements are smaller on pure write workloads.

MariaDB vs MySQL 8: growing divergence

The divergence between MariaDB and MySQL has kept growing since Oracle’s acquisition of Sun/MySQL. The most relevant differentiation points in 2024:

Community perception is also different: MariaDB has more open governance through the MariaDB Foundation; MySQL evolves more under the influence of Oracle’s needs and its MySQL HeatWave cloud^[4], whose vector store is the official route to embeddings in MySQL.

For teams that started with MySQL years ago and use MariaDB as a drop-in replacement, SQL and wire-protocol compatibility remains high for standard operations. Divergence shows up when a fork-specific feature comes into play: advanced replication, alternative storage engines, or, now, vector search.

MariaDB vs PostgreSQL

The comparison with PostgreSQL is different because these are distinct philosophies, not different versions of the same thing. If you want the PostgreSQL side of the equation, we already covered the PostgreSQL 17 query optimisations in detail:

• MariaDB: oriented toward MySQL compatibility, pluggable storage engines, Galera for multi-master high availability, very strong on read-heavy workloads with replicas.

• PostgreSQL: functional richness (advanced data types, extensibility, PostGIS, pgvector), robust ACID, better for complex analytical queries and advanced semi-structured JSON.

The choice is not "which one is better" but "for which specific workload". For web applications with dominant read patterns and teams familiar with MySQL, MariaDB remains a solid choice. For applications that need advanced JSON, geospatial types, or high-cardinality vector search, PostgreSQL with its extensions has more depth.

Galera Cluster: the HA differentiator

For teams needing distributed writes across multiple nodes with strong consistency, Galera Cluster remains the hardest argument to match in the MySQL/MariaDB ecosystem. MySQL Group Replication covers similar cases, but Galera has more production track record and a more active community of operators.

A typical Galera setup on Kubernetes with three active replicas:

# MariaDB Galera with the Percona operator
apiVersion: pxc.percona.com/v1
kind: PerconaXtraDBCluster
metadata:
  name: mariadb-galera
spec:
  crVersion: 1.14.0
  pxc:
    size: 3
    image: percona/percona-xtradb-cluster:8.0
  haproxy:
    enabled: true
    size: 2

For teams that already run this stack, upgrading to MariaDB 11.7 keeps Galera compatibility and adds the new functionality without architecture changes.

Conclusion

MariaDB 11.7 strengthens the argument for staying on MariaDB if you are already using it: native vector search without additional extensions, substantial JSON improvements, and incremental performance that justifies the upgrade effort. The argument for migrating to MySQL or PostgreSQL must be based on specific needs MariaDB does not cover, not on MySQL being "the original" or PostgreSQL being "the modern option". For web workloads with read replicas and Galera for HA, MariaDB 11.7 is a robust and actively developed platform.

Spanish version of this article: MariaDB 11.7: el fork que mantiene su propio camino.

Sources

1. official MariaDB announcement
2. official repository
3. official MariaDB Vector project page
4. MySQL HeatWave cloud