MariaDB 13.1 Feature in Focus: BLOB, TEXT, JSON and GEOMETRY Support in the HEAP Engine
Some contributions improve MariaDB Server by adding new capabilities.
Some go further: they start from a concrete production problem with an existing feature, not a bug, but a design limitation, solve it upstream, and leave the whole ecosystem better off.
This is one of those contributions.
The platform team at Headout, a global platform that helps travelers discover and book curated real-life experiences, encountered a few inefficiencies in MariaDB Server around temporary tables and the HEAP engine. Instead of treating these as isolated local problems, they worked upstream. Arcadiy Ivanov, operating through Karellen, Inc., took those real-world needs and turned them into a substantial contribution to MariaDB Server: support for BLOB, TEXT, JSON and GEOMETRY columns in the HEAP engine [1][2].
That deserves praise.
Not only because the work is technically impressive, but because the approach is exactly what makes open source stronger. A user finds a limitation. The limitation matters in production. The fix goes upstream. Headout benefits, but so does everyone else using MariaDB.
This is the kind of contribution MariaDB Foundation loves to see.
What Changed?
The HEAP engine, also known as the MEMORY engine, is designed for in-memory tables. It is especially important for internal temporary tables, where MariaDB may need to materialize intermediate results during query execution.
Before this work, HEAP could not handle BLOB or TEXT columns. That also affected the JSON and GEOMETRY use cases because those types are represented internally as BLOBs.
The result was simple:
If an internal temporary table needed BLOB or TEXT data, MariaDB could not keep it in HEAP.
It had to use a disk-based temporary table instead.
That can be fine when the data is large. But it is not ideal when the data is small enough to fit in memory. In those cases, falling back to disk is unnecessary work, and as we all know, disks are always slower than RAM.
With this contribution, MariaDB Server can keep more of these temporary tables in memory when they fit within the configured limits.
That makes a big difference!
Why This Matters
At first glance, support for BLOB, TEXT, JSON, and GEOMETRY columns in HEAP may seem like a storage engine detail. It is not just that. Modern applications use JSON more and more. They use dynamic data structures. They use spatial data. They use text fields. And SQL operations such as:
- GROUP BY
- DISTINCT
- UNION
- Subqueries
- Common Table Expressions (CTEs)often create internal temporary tables.
If those temporary tables contain BLOB, TEXT, JSON or GEOMETRY values, the database should not be forced to move to disk just because of the column type.
It should make the best choice based on the actual data and memory limits.
That is what this work improves.
The practical effect is that more real-world queries can stay in memory. That can reduce temporary file creation, reduce disk-engine overhead, and make execution more efficient for workloads that use JSON, TEXT or GEOMETRY data.
That is a very useful improvement.
Overview of the solution
This is an illustration of the changes brought by this contribution:
A Real-World Contribution
What makes this contribution especially important is where it came from.
This was not an abstract feature request created in isolation. The Headout platform team encountered real issues while using MariaDB Server. They found cases where MariaDB could behave better. They identified bugs and inefficiencies that mattered to them.
And Arcadiy Ivanov addressed them upstream.
That is worth highlighting.
Open source works best when production experience flows back into the project. When companies using MariaDB Server contribute fixes and improvements upstream, they are not only solving their own immediate problems. They are improving the server for other users, other companies, and future workloads they may never see.
This contribution is a strong example of that model.
Headout benefits.
MariaDB users benefit.
The ecosystem benefits.
A Big Feature, Not a Small Patch
This was not a tiny change.
Supporting BLOB-like values in HEAP requires more than removing a restriction. The engine needs a way to store variable-length data while still working with its existing in-memory record structures.
Arcadiy’s implementation does this by storing BLOB data in continuation records. In simple terms, the normal HEAP row remains in memory, and larger variable-length values are stored in additional records connected to it.
That allows the engine to keep using its in-memory allocation model while supporting data that does not fit neatly into a fixed-width row.
The actual implementation is careful about memory usage and record layout. Continuation records can be organized in different forms depending on the shape of the stored value, and the implementation avoids unnecessary per-record overhead where possible. That is an important detail: this is not just a simple “attach extra rows” mechanism, but an implementation designed to fit naturally into HEAP’s existing in-memory architecture.
There is also important work around hash indexes, comparisons, temporary-table behavior, and query operations such as GROUP BY, DISTINCT, and UNION.
That is the part I really appreciate.
It is one thing to make a type fit into a storage format.
It is another thing to make it behave correctly across the SQL operations users actually run.
If you are interested, here are two illustrations about the record layout & block structure and variable-lenght continuation runs.
JSON and GEOMETRY Become More Natural
JSON-heavy schemas are common today.
GEOMETRY is important for spatial applications.
Both can appear in intermediate query results. Both can be part of real workloads where temporary tables appear naturally.
With this work, MariaDB Server becomes better prepared for those workloads.
A query using JSON or GEOMETRY should not automatically lose the benefits of in-memory temporary tables just because an intermediate result contains one of those types.
This is what users expect, as they are not always aware of these limitations of the old HEAP engine.
Additional Benefits: Indexes and System Metadata Queries
There are two additional benefits worth calling out.
First, this work also matters for indexes. Supporting BLOB-like values in HEAP is not only about storing the data. The contribution also adds proper HASH index handling for BLOB columns, so operations such as GROUP BY, DISTINCT, and UNION can compare and deduplicate BLOB, TEXT, JSON, and GEOMETRY values correctly while staying in the MEMORY engine. That means more queries can use in-memory hash access instead of being pushed toward a disk-based temporary table just because the indexed or grouped value is blob-like.
Second, this also helps with system metadata and instrumentation queries. INFORMATION_SCHEMA and PERFORMANCE_SCHEMA tables and views often expose textual metadata, definitions, statements, or diagnostic values. Some of these result sets contain TEXT or BLOB-like columns, which previously made it easier for internal temporary tables to fall back to Aria. With this contribution, more of those system-query temporary tables can remain MEMORY tables when they fit in the configured memory limits. That is useful not only for application queries, but also for DBAs and tools that query metadata, routines, views, events, parameters, status, or performance-related information.
Thank You, Arcadiy
Arcadiy Ivanov deserves a sincere thank-you for this work.
This is a deep, careful, and useful contribution. It touches storage-engine internals, SQL-layer behavior, temporary-table handling, indexes, testing, and real-world correctness issues.
It also shows the best kind of open source engineering: start from an actual need, understand the root cause, solve it properly, and contribute the result upstream.
That is not always the easiest path. But it is the path that creates lasting value.
So thank you to Arcadiy Ivanov and Karellen, Inc. for the contribution, and thank you to the Headout platform team for bringing these real-world needs to MariaDB Server in a way that benefits the wider community. Not everybody shares their patches upstream, but doing so strengthens the product as a whole.
Try It and Give Feedback
Features like this are especially important to test with real workloads.
If you use JSON, TEXT, BLOB or GEOMETRY data, and your queries create temporary tables through GROUP BY, DISTINCT, UNION, subqueries or CTEs, this is a feature worth paying attention to.
Try it.
Test the queries that matter in your environment.
Look at temporary-table behavior.
And, as always, give feedback upstream; this is the perfect time with MariaDB Server 13.1 preview.
That feedback is what helps MariaDB Server keep improving for everyone.
As usual, enjoy MariaDB and happy testing!
