Your system runs, but nobody knows it in detail. We record application, database, server and email, assess the risks, recommend the next step in writing and, if you wish, take over operations.
MySQL, MariaDB and Galera: running and migrating databases
Our engineers run MySQL and MariaDB, also as Galera clusters, and move data between databases, for example from Firebird to MariaDB. They also look after PostgreSQL, Microsoft SQL Server and Oracle databases.
- MySQL and MariaDB since 2012, also in Galera clusters
- Migrations between databases, for example from Firebird to MariaDB
- Reply within one working day
Where we use databases
Behind every web application there is a database, and it is often the part nobody touches. Usually it is MySQL or MariaDB, on the same server for years, with a configuration that nobody wrote down. Our engineers have worked with these two systems since 2012: installation, backups, replication, Galera clusters, performance and updates.
Our engineers also work with PostgreSQL, Microsoft SQL Server and Oracle, in applications whose data lives there and in interfaces to such systems. They know Firebird mainly from migrations.
How we back up MySQL and MariaDB in operation and keep them available is described on the page MySQL and MariaDB databases.
Typical tasks with MySQL and MariaDB
- Inventory: version, configuration, backups, users and permissions, size and growth of the data
- Backups with binary logs and a regular restore test
- Setting up and monitoring replication and Galera clusters, and bringing them back together after a failure
- Finding slow queries, adding indexes and adjusting the configuration, in the application code too where necessary
- Updates and new major versions, tested on a copy first
- Switching between MySQL and MariaDB, and migrations from other databases
- Cleaning up character sets when accented characters appear garbled after a move
- Moving the database to a new server or into a container, with persistent storage and a way back
MariaDB and MySQL: similar, but not the same
MariaDB started as a fork of MySQL, and many applications run on both. With every major version, however, the two have drifted further apart. For operations, three differences matter most.
High availability. Galera is already included in MariaDB. For MySQL, Galera exists as a separate server variant, alongside MySQL's own group replication. Which path fits depends on what you already run.
Replication between the two. The two systems identify transactions in replication differently. A mixed setup of MySQL and MariaDB is therefore possible only to a limited extent, and it suits a migration better than permanent operation.
Functions and optimiser. The JSON data type, individual functions and the optimiser behave differently. The same query can be fast on one system and slow on the other. Before a switch, we therefore test the application against a copy.
Migrations between databases
An application rarely changes its database without a reason. Common reasons are a system nobody on the team knows any more, or old drivers that stop working with new versions of the application. Sometimes all applications are meant to run on one database. A typical example is the move from Firebird to MariaDB.
More changes than the place where the data is stored. Data types, character sets, stored procedures, triggers and the SQL dialect differ, and the queries in the code have to follow. We therefore migrate on a copy first, compare the data with the original and switch over only after the tests.
If a database runs stably and is maintained, we do not advise a switch just because another system looks more modern.
Technologies and scope
| Area | Scope |
|---|---|
| MySQL and MariaDB | Installation, backups with restore tests, replication, performance and updates |
| High availability | Galera clusters with MySQL and MariaDB, replication with a planned switchover |
| Firebird | Migrations, for example to MariaDB |
| PostgreSQL, Microsoft SQL Server and Oracle | Applications whose data lives in these databases, and interfaces to them |
| Operations underneath | Linux with Debian and Ubuntu, Docker, KVM and Proxmox |
Typical starting points with databases
-
-
Security updates for PHP 8.2 end on 31 December 2026, and for PHP 8.1 and older they have already ended (As of 2026-10). We move long-running PHP applications, including those with Smarty templates and jQuery front ends, to PHP 8.4 or 8.5 and test every stage.
-
Is your data being copied by hand between two systems today, or does a partner require an API? We connect existing applications via REST or SOAP, synchronise data between them and send transactional emails and notifications from your workflows.
-
Your team is at capacity, a specific skill is missing, or you need a second opinion before an important decision? We take over a defined part: a module, the backend for your frontend, an interface, a migration or a code review. We work in your repository and ticket system, and the code and the knowledge stay with you.
The first step: a database check with written findings
Database check: MySQL and MariaDB
For companies whose application depends on a MySQL or MariaDB database and who want to know what happens in a failure and whether yesterday's data can really be restored.
- Backups: what is backed up, how often and where the copies are kept
- A restore test on a separate system, with the time it takes measured
- Replication and resilience: what exists and what is missing
- The slowest queries and missing indexes
- Version, support status and configuration
- Recommendation: backup, replication or cluster, depending on your needs
A cluster such as MariaDB Galera protects against the failure of a server, not against deleted data. That takes tested backups, which is why we start with the restore test. We agree with you on the system it runs on. We change nothing on your production database.
What the result contains
A written report with the result of the restore test, the risks in order of priority and a recommendation with the effort involved. The report is yours. If you wish, we then set up the solution, including a Galera cluster.
Projects with MariaDB
-
SQL indexes in a shop database: from full scans to microseconds
A shop database without indexes worked as long as the tables were small. At 500 000 orders and 1.75 million order items every filter and every join came down to a full scan. We measured exactly what the missing indexes cost, added the right ones, and documented the traps that make an index useless even though it exists.
-
ColdFusion under load: diagnosing and fixing the JVM heap space error
An Adobe ColdFusion application ran without complaint at low traffic and returned errors and slowed down at peak hours. We reproduced the problem on a real database, measured the exact point at which the JVM heap runs out, and fixed the memory configuration, with the same load test before and after as the proof.
Questions about MySQL, MariaDB and other databases
MySQL or MariaDB: what is the difference?
MariaDB started as a fork of MySQL. For many applications the two are interchangeable: essentially the same SQL, similar tools and a similar configuration. With every major version, however, they have drifted further apart, for example in replication, the JSON data type, individual functions and the optimiser.
A switch is therefore more than swapping the software. We first check which functions your application uses, move the data on a copy and test the application against it. Only then do we switch over, in an agreed time window and with a way back.
How does a database switch work, for example from Firebird to MariaDB?
We start with an inventory: tables, data types, character sets, stored procedures, triggers and the queries in the application. Firebird and MariaDB speak different SQL dialects, so we translate schema and logic and adapt the queries in the code.
Then we migrate the data on a copy and compare it with the original, table by table. We test the application against the new database before switching over in an agreed time window. Until the new setup runs stably, the old database remains as a way back.
Do you also work with PostgreSQL, Microsoft SQL Server or Oracle?
Yes: in applications whose data lives in these databases, and in interfaces to such systems. Our engineers know Firebird mainly from migrations, for example to MariaDB.
With MySQL and MariaDB, also in Galera clusters, we also take on operations, backups and high availability. For the other databases, we say openly in the intro call what we take on and where your team or a specialist provider fits better.
How do you upgrade MySQL or MariaDB to a new major version?
On a copy first. We check which settings, SQL modes and functions change in the new version and which of them your application uses. Then we restore a current backup on a separate system, upgrade it and test the application against it.
Where the environment allows, we build the new server alongside the old one and keep it in sync through replication. The switchover is then short and takes place in an agreed time window. The old server, with the state before the switchover, remains as a way back.
Does a Galera cluster replace data backups?
No. A cluster protects against the failure of a server, not against deleted data. Every change reaches all nodes, including an accidental deletion or a faulty update. The data is then missing on all servers at once.
That takes tested backups outside the cluster. Depending on the setup, binary logs can also bring back a state shortly before the error. Only a restore test shows whether that works, which is why our database check starts with one.
Not sure which service fits your system?
Describe your system in two sentences. We will tell you which service fits and whether an entry product at a fixed price is the right first step.