In my previous post, I introduced the MariaDB Privacy-First Stack.
Nextcloud for collaboration, Passbolt for passwords and secrets, and MariaDB Server for the data.
Simple enough.
But after explaining what the stack is, the next question is usually very practical:
Where can I deploy it?
And the answer should not be:
On the cloud provider the template was written for.
That would be a strange way to talk about digital sovereignty.
If the architecture is really meant to give you more control, you should also have some freedom regarding where it runs.
…
Continue reading “Deploying the MariaDB Privacy-First Stack Anywhere with Terraform”
Database migrations are rarely only about replacing one database server with another.
In real production systems, especially in fintech, a migration is usually about reducing risk, keeping the application online, improving scalability, and giving teams more room to evolve the architecture without freezing product development.
This story is about a fintech B2B enterprise that migrated from a monolithic PostgreSQL 12 environment to MariaDB 11. The company runs a payments-related platform for discounts and cashback, where users can check balances, transaction history, applicable discounts, and other account information. The payment-related part of the workload was mostly transactional, while the rest was mixed, with roughly 60% reads and 40% writes.
…
Continue reading “From PostgreSQL 12 to MariaDB 11: A Gradual Fintech Migration with 23% Lower TCO”
Have you ever modified a MariaDB configuration file, restarted the service, and immediately regretted it?
You wanted to change:
innodb_buffer_pool_size=16G
but accidentally wrote:
innodb_buffer_pool_sze=16G
One missing letter.
That is enough to turn a perfectly healthy database server into a service that refuses to start.
And of course, this kind of mistake never happens during a quiet maintenance window when everybody is available.
It happens during an automated deployment.
It happens during an upgrade.
It happens on a remote server.
Or it happens just before you planned to leave for dinner.
…
When people hear “online schema change” in the MySQL and MariaDB world, many immediately think about pt-online-schema-change. And for good reasons: for years, changing a large table in production was one of those tasks that could ruin your day.
Recently, I discovered that MariaDB includes a very useful hidden gem I completely missed: the ability to update a table schema without blocking concurrent DML statements for the duration of the schema change. [1]
As you probably already know, MariaDB Server supports multiple schema change algorithms.
This is an overview summary:
| ALGORITHM=INSTANT | Metadata-only change. |
…
Continue reading “MariaDB Hidden Gem: Online Schema Change without pt-osc”
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.
…
Interview with Federico Razzoli, nominated in the Community Leadership category.
The MariaDB Foundation Sea Lion Champions program celebrates the people and organizations who help make the MariaDB ecosystem stronger, more open, and more useful for everyone.
Behind every open-source project, there are contributors whose work takes many forms. Some write code. Some review, test, document, teach, organize, advocate, support users, build tools, or bring MariaDB into production environments where it proves its value every day. Together, they help MariaDB remain a vibrant, collaborative, and industry-relevant database platform.
To highlight this diversity of contributions, we are launching a new series of interviews with nominees for the MariaDB Foundation Sea Lion Champions program.
…
Continue reading “MariaDB Foundation Sea Lion Champions Nominees: Federico Razzoli”
TAF 3.0 introduces the new TAF Results Backend, a structured results database and parser pipeline that delivers fully automated performance change detection. This system uses a deterministic workload hash, schema‑driven baselines, and stored‑procedure‑driven comparison. No procedural comparison code. No special‑case logic. Everything is clean and automatic.
Workload Hash
Every test run gets a workload hash and parser builds it from:
- test + suite identity
- system identity
- database maker + engine
- database version normalized to major only (MariaDB, MySQL, PG, any maker)
- configuration identity
- workload parameters (threads, rows, tables, ranges, warmup, connector)
- harness + client versions
- iteration count
- requested duration
This hash is the identity of the workload.
…
Continue reading “TAF 3.0 — Results Backend With Automated Performance Change Detection”
During the last MariaDB Foundation Board Meeting (24 June 2026), Barry shared how it can be difficult to deploy an upgrade immediately and that they sometimes have to wait for one that fixes security bugs. Wait for the validation, wait for the fix, and the release. Even if the MariaDB engineers are doing incredible work, it might still not be fast enough for the security team.
That’s where Barry requested MariaDB implement a query-rewriter plugin, like the one in MySQL, to address the fact that, in a multi-tenant environment, certain queries that would trigger known vulnerabilities are never legitimately used by applications.
…
Continue reading “MariaDB Server Plugins: disabled functions”