MariaDB development
The MySQL-compatible database behind a great many PHP applications, with an open governance model and a few useful storage engines of its own.
Relational database
Chosen per project
Maintainable handover
MariaDB began as a drop-in replacement for MySQL and remains close enough that most applications move without code changes. For teams uneasy about MySQL’s ownership, or wanting engines like Aria and ColumnStore, it is a straightforward choice.
In practice the work is the same as any relational database: a schema that matches how the data is actually queried, indexes that support those queries, and replication configured before it is needed rather than during an incident.
What we build with MariaDB
PHP and WordPress-based applications at scale
Migrating from MySQL without an application rewrite
Read-heavy workloads served from replicas
Cost-sensitive systems needing a solid open-source database
Where it fits — and where it does not
Good fit when
Web applications with relational data
Existing MySQL codebases
Environments where licensing cost is a factor
Consider something else when
Workloads relying on PostgreSQL-specific features such as rich JSON indexing
Very large analytical scans, better served by a warehouse
Where database speed actually comes from
In cost order, cheapest first. Most systems never need to reach the bottom.
The right index
Often a single index changes everything.
A better query
Remove a scan, avoid a temporary table.
Schema change
Denormalise or split where the shape is wrong.
Read replica
Move reporting load off the primary.
Bigger machine
Last, and least often the real answer.
How we work with MariaDB
Schema for the queries
Table and index design driven by the queries that will actually run, not by an ORM default.
Slow query log first
Optimisation starts from measured slow queries rather than intuition about which page feels sluggish.
Replication before it is urgent
A replica configured for reads and as a recovery option, tested while nothing is on fire.
Backups verified
Logical or physical backups on a schedule, with a documented restore that has been run.
Our typical MariaDB setup
| Concern | What we use |
|---|---|
| Engines | InnoDB for transactional work; Aria and ColumnStore where they fit |
| Diagnosis | Slow query log, EXPLAIN, performance schema |
| Replication | Asynchronous replicas for reads and recovery |
| Backups | mariabackup or logical dumps, with tested restores |
| Hosting | Self-managed, or managed MySQL-compatible cloud services |
Frequently asked questions
For most applications it is uneventful, because the wire protocol and SQL dialect are compatible. The care is needed around version-specific features and any replication topology, which we would check before committing.
If the team and the ecosystem are PHP-centred, MariaDB is the path of least resistance. For richer data types, stricter constraints and advanced indexing, PostgreSQL is usually the stronger engine.
Usually, and usually without touching the application. It starts with the slow query log rather than a rewrite.
Services built with MariaDB
Web Application Development
Applications that run in the browser, handle real workloads and hold up when several departments depend on them at once.
Custom Software Development
Software shaped around the way your business already works, instead of a packaged product you have to reorganise around.
E-commerce Development
Online stores where the checkout works, the stock figures are real and the order data reaches your operations team intact.
Software Maintenance
Keeping working systems working — including ones built by somebody else.
Tell us what you are trying to build
Describe the problem in plain language and we will tell you what it would take to solve it — the approach, the moving parts and the sensible order to build them in. No obligation either way.