What is the difference between MySQL and MariaDB? Why don’t you offer MySQL?
MariaDB is a fork of MySQL, initiated by the original lead developer of MySQL after Oracle acquired MySQL. The goal was to continue developing the software while maintaining 100% compatibility (binary compatibility) with MySQL.
Thanks to the constant maintenance of the project by the community, many providers and a large part of all Linux distributions have recently switched to MariaDB as the SQL server. To also offer you a modern SQL database solution, we follow suit and configure all our database servers with MariaDB.
Compatibility in practice: will my MySQL-based CMS/app work on MariaDB?
For most customers, the practical answer is yes: if your application supports MySQL, it will typically run on MariaDB without requiring code changes. MariaDB was created as a MySQL fork with the explicit goal of maintaining compatibility, and in many hosting environments it is used as a drop-in replacement. This is why typical web applications, such as WordPress, Joomla, Drupal, and many PHP-based systems, generally work the same way on MariaDB as they do on MySQL.
However, “compatible” should be understood pragmatically. Most compatibility concerns are not about basic connectivity or standard queries, but about specific features, server defaults, or version differences. If your application uses standard SQL patterns and relies on widely used MySQL drivers (for example, mysqli or PDO in PHP), MariaDB is usually seamless.
If you are migrating an existing site, the best confirmation is operational: import the database, load the application, and validate core workflows (login, content creation, checkout, admin actions). In most cases, this is sufficient to confirm that MariaDB behaves as expected.
Where compatibility can differ: versions, SQL modes, and edge cases
Even when MariaDB and MySQL are broadly compatible, behavior can differ in edge cases, especially when moving between different major versions or when server defaults are not identical. Most issues arise from differences in strictness, SQL modes, and feature availability across specific versions.
Typical areas where differences may show up:
- Server version differences: importing from a newer MySQL version into an older MariaDB version (or vice versa) can surface syntax or feature mismatches.
- SQL mode and strictness: applications that rely on permissive behavior may break if strict settings are enabled, and the reverse can happen as well.
- Character sets and collations: differences in default charset/collation handling can cause sorting or comparison behavior changes, especially with older databases.
- Feature-specific queries: applications using niche features or vendor-specific behavior may behave differently, even if most of the database works.
This is not a reason to avoid MariaDB; it simply means you should treat database migrations as a compatibility check between versions, not just between product names. When issues occur, they are usually solvable by aligning versions, adjusting SQL mode, or updating the application to a version that cleanly supports the target database environment.
If you’re migrating from another provider: what to check before importing a database
If you are moving a database from another hosting provider, a quick pre-check can prevent the most common import failures and post-migration surprises. The goal is to ensure that what you export can be restored cleanly and that the application can connect and operate normally afterwards.
Recommended pre-migration checks:
- Confirm the source database type and version (MySQL/MariaDB and version number).
- Confirm the database character set and collation, especially for older projects or multilingual content.
- Ensure your export is complete and consistent (a full dump of schema and data).
- Identify whether your application uses stored procedures, triggers, or events. These can require additional privileges or specific dump options.
- Plan the cutover so you can run a quick validation before putting production traffic on the migrated system.
After import, validate both data and application behavior. The migration is complete only when the application can read and write data reliably, and core workflows function as expected.
When to contact support: the minimum technical details that speed up resolution
If you run into database issues after migration or during regular operation, providing a small set of specific details upfront typically significantly reduces resolution time. Database problems are hard to diagnose from symptoms alone, so the goal is to supply enough context to reproduce or pinpoint the error quickly.
Include these details in your request:
- The domain or project affected, and whether the issue is new or after a recent change.
- The exact error message, copied verbatim (from the application, logs, or database import output).
- The time of occurrence and whether it is constant or intermittent.
- The application/CMS name and version (for example, WordPress version).
- Whether the issue occurred during import, during normal website use, or during a specific function (login, saving content, checkout).
- If relevant, confirm whether this started after a migration and from which environment/version.
This information allows support to quickly determine whether the issue is an import compatibility problem, a configuration mismatch, or an application-level query error.