What we use MariaDB for
MariaDB runs under every system we look after. Shopware 6 keeps products, prices, customers and orders in it, TYPO3 its page trees and content, WordPress its posts. Then there are custom applications on PHP 8 and Symfony, where we design the schema ourselves — the business logic first, the tables after. Straightening out a data model later is paid for over years, in migrations.
A second large part of the work is grown data from legacy systems. Tables without foreign keys, a mix of latin1 and utf8 character sets, columns whose meaning nobody remembers. We move such data into a clean model, switch everything to utf8mb4 and write down the decisions we make along the way. It is unspectacular work. It does decide, though, whether a later migration is an appointment or a project.
How we work: measure first, then act
Before anyone talks about bigger hardware, we switch on the slow query log and look at which queries actually cost time. Then comes EXPLAIN: is the database reading half the table because an index is missing, or because the condition is written in a way that stops the index being used? Usually it is that. A composite index in the right place replaces more server capacity than a quote would suggest.
In Symfony applications, schema changes run through Doctrine migrations, versioned and rehearsed on a copy before they go live. Backups are part of managed hosting on our own servers in Germany — with a restore test. A backup that has never been restored is a guess. We also monitor connections, buffer sizes and disk space, because a full disk stops a database faster than any traffic peak.
When you do not need a database project
Not every slow page is a database case. When a shop with two orders a day feels sluggish, it is more often uncompressed images, an overloaded front end, or an interface waiting synchronously on an ERP. We measure that before writing a quote for database work. Sometimes the honest answer is that there is nothing to optimise here and the problem sits elsewhere.
Mid-sized projects just as rarely need a database cluster, a second database technology alongside, or a split across several servers. A well-designed MariaDB instance carries normal shop and portal load without contortions. Introducing replication, sharding and an additional store buys operational work that somebody has to carry permanently. That can be the right call. It should only be a decision, not a reflex.