Elestio Joins the MariaDB Foundation as a Silver Sponsor

Some news we're genuinely happy about: Elestio is now a Silver Sponsor of the MariaDB Foundation. The Foundation announced it today.

We run a lot of MariaDB for a lot of people. Every managed MariaDB instance on Elestio relies on the work of people we've never met: the engineers who fix security bugs, cut releases and keep the server open. Funding that work directly felt overdue.

Below is what the Foundation does, why we sponsor it, and (since this is still a technical blog) a practical check you should run on your own MariaDB this week.

The Foundation Is Not the Company

People mix these up all the time, so let's clear it up. MariaDB started in 2009 as a fork of MySQL, around the time Oracle was acquiring Sun. Two organizations carry the name today:

• MariaDB plc is the commercial company that sells enterprise products and support.
• The MariaDB Foundation is the non-profit that safeguards the openness, development and continuity of MariaDB Server, the open-source database you actually run.

Sponsorship money goes to the Foundation. According to its sponsor page, that money pays for server maintenance and development, security fixes and coordinated releases, documentation, contributor support, and testing and QA infrastructure. It's the unglamorous work that keeps a database boring in the best way.

Why We Sponsor It

Managed hosting providers have an awkward relationship with open source. We build a business on software other people write. The honest way to handle that is to put money back into the projects our customers depend on.

Here's how our CTO Joseph Benguira put it in the Foundation's announcement:

"Our customers choose MariaDB because it is fully open source, works with the applications and tools they already use, and can run on the cloud provider and in the region that suit them. We see steady demand from customers and supporting MariaDB Foundation is an investment in the software those customers rely on every day. We encourage other providers building on MariaDB to do the same."

Anna Widenius, CEO of the MariaDB Foundation, added:

"We want more teams to have clear, practical ways to run MariaDB. Managed-service providers make that possible for customers with different infrastructure needs and operational resources. We are delighted to welcome Elestio as a sponsor and encourage other providers building services around MariaDB to support the project."

To be clear about what changes for you: your pricing and your instance stay the same. What you get is indirect but real: the security releases and fixes that reach your database through updates are funded, in part, by sponsors like us.

While You're Here: Check Your MariaDB Version

Here's the practical part. MariaDB 10.6 reached end of life on July 6, 2026. A final 10.6.28 release shipped in August, and that's the end of the line. It was a popular long-term support (LTS) release, so plenty of production databases are still on it, and they won't get any more security fixes.

These are the LTS lines as of today, according to MariaDB's official release API:

Check what you're running. Replace mariadb with the service name from your docker-compose.yml:

docker compose exec mariadb mariadb -uroot -p -e "SELECT VERSION();"

If the answer starts with 10.6 (or anything older), plan the upgrade.

Upgrading Without the Drama

1. Take a logical backup first. Elestio's automated backups already cover your VM. For a major-version jump, you also want a portable dump you can restore anywhere. List your application databases and leave out the mysql system schema, since the new version creates its own:

read -s -p "MariaDB root password: " DBPASS; echo
docker compose exec -T mariadb mariadb-dump -uroot -p"$DBPASS" \
  --databases app_db another_db \
  --single-transaction --routines --events --triggers > backup-$(date +%F).sql

Users and grants live in that system schema, so note them separately (SHOW GRANTS FOR 'app'@'%';) if you'll restore elsewhere.

2. Test on a copy. Restore that dump into a second instance running the target version and point a staging copy of your app at it. Most upgrades are uneventful. Testing is how you find out whether yours is one of them.

3. Bump the image tag and let the container upgrade itself. On Elestio, the stack's docker-compose.yml lives under /opt/app/ on your VM. If it uses the official MariaDB image, that image can run mariadb-upgrade on startup when you set MARIADB_AUTO_UPGRADE. It also saves a backup of the system tables in the data directory, in case you ever need to downgrade:

services:
  mariadb:
    image: mariadb:11.8
    environment:
      MARIADB_AUTO_UPGRADE: "1"

Then run docker compose up -d and check SELECT VERSION(); again.

Troubleshooting

Unknown collation: 'utf8mb4_uca1400_ai_ci' when restoring a dump. MariaDB 11.8 defaults to utf8mb4 with the utf8mb4_uca1400_ai_ci collation. Dumps taken from it won't import into older MariaDB versions or MySQL that don't know that collation. Restore into the same or a newer version. If you really must go backwards, rewrite the collation in the dump first:

sed 's/utf8mb4_uca1400_ai_ci/utf8mb4_unicode_ci/g' backup.sql > backup-compat.sql

Warnings about outdated mysql.* tables after the image bump. mariadb-upgrade never ran, usually because MARIADB_AUTO_UPGRADE wasn't set. Check docker compose logs mariadb, then run it by hand:

docker compose exec mariadb mariadb-upgrade -uroot -p

Apps break on stricter defaults. Major versions sometimes change SQL modes or optimizer behavior. This is exactly what step 2 is for. Run your app's test suite against the new version before production sees it.

What's Next

We'll keep running MariaDB the way you'd want it run: updated, backed up and on the cloud provider and region you choose, starting at $11/month for the VM, with no license fees. If your company builds on MariaDB too, the Foundation explains how to become a sponsor. The more of us chip in, the healthier the database we all depend on.

Thanks for reading ❤️ See you in the next one 👋