GICT knowledge base
Check MariaDB Versions and Compatibility on Shared Hosting
Published
The MariaDB/MySQL version available to a shared-hosting website is a property of its assigned database service. Check the actual server version and your application’s requirements before assuming that a particular major or point release is available on every hosting node.
Check the version your website uses
Use the authenticated database information in your panel/phpMyAdmin or run this read-only query through an authorized database connection:
SELECT VERSION();
Record the full result and which database host the application uses. A local client version does not necessarily identify a remote database server, and a result from the Tips server would not describe the entire shared-hosting fleet.
Compare requirements, maintenance and compatibility
Use the application’s current supported database requirements and the vendor’s maintenance schedule. WordPress’s minimum/recommended requirements are not a guarantee that every plugin, SQL query or schema supports a chosen release.
MariaDB’s current maintenance table distinguishes community, enterprise and extended maintenance. MariaDB 10.6 community maintenance ended on July 6, 2026; enterprise or vendor-specific maintenance can differ. This article has not audited each InterServer node’s patch source or support contract and does not infer patch status from a version string alone.
The earlier “point release above .20” stability rule and unconditional version ranking are withdrawn. A point-release number does not prove that a version is the most stable choice for your application. Use current fixes, a supported lifecycle and application testing rather than a numerical threshold.
Request compatibility information before a move
If an application needs another database release, open a support ticket with the destination service, current database host/version, required release and application details. Ask what supported options are actually available; do not assume that a specific version can be installed independently on a shared server.
An in-place upgrade and moving to another hosting node have different risks. There is no universal five-minute downtime guarantee. Export/import, authentication methods, SQL behavior, runtime/extensions and large database size can affect compatibility and duration.
Prepare and test deliberately
Preserve a verified database and website backup, plan a separate test environment and arrange how writes are reconciled. Test login, database-backed actions, jobs and important queries without triggering duplicate mail/payments.
If a node move is agreed, confirm IP/DNS changes and mail scope, keep the source until accepted and record rollback settings. InterServer’s complimentary migrations cover matching-panel web hosting transfers only, not cross-panel, VPS or dedicated-server moves.
Additional reference: current WordPress requirements. Reviewed October 14, 2026. No database upgrade, fleet-wide version audit or customer-node move was performed.
Related guides
Migrate WordPress with Migrate Guru: Scope and Safety Checks
Use Migrate Guru for a scoped WordPress copy. Review third-party processing, protect the destination and verify the application before changing DNS.
MigrationcPanel to DirectAdmin: Conversion, Restore and Verification
Convert a supported cPanel account archive to DirectAdmin with private delivery, ownership mapping and application/mail checks before DNS cutover.
MigrationcPanel to CWP: Private Backup Import and Recovery Checks
Plan a self-managed cPanel-to-CWP import. Transfer backups privately, check account conflicts and verify websites, mail and DNS before cutover.
MigrationcPanel to Webuzo: Self-Managed Import and Verification
Plan a cPanel-to-Webuzo conversion using current import tools, private archives and deliberate overwrite choices. Verify mail, databases and applications.
