Headout, an events booking platform running MariaDB on AWS RDS at 10,000-30,000 queries per second, hit a production bottleneck: heavy JSON usage led to BLOB data in internal temporary tables, forcing expensive disk-based processing instead of in-memory handling. Since Headout couldn't modify the managed RDS infrastructure or rewrite queries across its autonomous engineering pods, engineer Arcadiy Ivanov worked directly with MariaDB's Monty Widenius to add BLOB support to in-memory internal temporary tables, using Claude Opus 4.6 as an assisted coding tool under close human supervision. The feature landed in the MariaDB 13.1 preview series rather than a 10.11 maintenance release. The piece details the iterative collaboration, including Monty's candid assessment of where the LLM succeeded (test generation, code review, comments) and failed (code duplication, patching symptoms instead of root causes, structural hacks), and reflects on why upstream contribution beats maintaining a private fork.
Table of contents
It Started With a Real Production ProblemWhat Moving These Temporary Tables to Memory Changes“Let Me Give It a Try”A Patch Intended for 10.11 Finds Another PathWorking Directly With the People Who Know the CodeOpen Source Is Also a Maintenance DecisionThe Process Was Not PerfectWhy This Collaboration MattersAnd Now?ConclusionQuestions this post answers
Does MariaDB support BLOB values in in-memory internal temporary tables?
Yes, as of the MariaDB 13.1 preview series, in-memory internal temporary tables can store BLOB values, including those from JSON columns. Previously, temporary tables containing BLOB data could not use the faster in-memory path and had to fall back to a more expensive disk-based path, causing performance bottlenecks for workloads with heavy JSON usage, UNION operations, or common table expressions. The change was contributed by Arcadiy Ivanov and reviewed by MariaDB's Monty Widenius. Teams tuning MariaDB workloads can track feature maturity toward stable releases on daily.dev.
Why did Headout choose to fix its MariaDB temporary table bottleneck upstream instead of patching it privately?
Headout runs MariaDB on AWS RDS, a managed service where the underlying host cannot be reconfigured, so a private patch would never reach production. Beyond that constraint, maintaining a private fork creates a permanent maintenance burden of merging every upstream release and re-resolving conflicts, so contributing the fix upstream turns a private liability into shared, maintained infrastructure once it ships in an official release. Engineers weighing forks versus upstream contributions can follow similar open-source case studies on daily.dev.
What are common failure patterns when using Claude Opus 4.6 for complex code contributions to an existing codebase?
According to MariaDB maintainer Monty Widenius, Claude Opus 4.6 tended to duplicate existing code paths instead of reusing them, patched symptoms rather than fixing root causes because structural fixes touch more code, and sometimes altered interfaces (like the memory engine's handler interface) in ugly, error-prone ways rather than changing the correct layer. It performed well at generating tests, reviewing code, and writing comments, but faulty code still required extensive human review and testing. Developers evaluating AI coding assistants for real production changes can compare experiences like this on daily.dev.