Why I Would Think Twice Before Running WordPress on SQLite at Xserver

I had been running my WordPress blog on Xserver using SQLite Database Integration.
I liked both, and the combination had worked well for me.
Then an attempt to update the SQLite plugin to v3 produced an error.
Digging into it revealed a limitation in my hosting environment that I hadn't anticipated.

I was happy with both Xserver and SQLite

Xserver's control panel is easy to use, and switching PHP versions takes little effort.
It also offers automated backups and restore options, along with performance and security features.
For the price, I was happy with what I was getting.

SQLite appealed to me for a different reason: simplicity.
A database stored in a file seemed like a good fit for a small blog, without having to think about a separate MySQL or MariaDB database service.
That file-based approach also seemed compatible with Xserver's file backup and restore features.
Of course, copying a database file while it is in use does not automatically guarantee a consistent backup.

I liked the setup enough to write an earlier introduction to SQLite Database Integration.
I hadn't run into any major problems in day-to-day use, so I expected the v3 update to be routine.

PHP was up to date, but SQLite wasn't

Version 3.0 of SQLite Database Integration introduced a revised driver that translates MySQL-oriented queries for SQLite.
The changes promised better compatibility, but the primary SQLite requirement was raised to 3.37.0 or later.

A limited compatibility mode covers SQLite 3.27.0 through the 3.36 series.
My environment fell below even that range.

I was surprised.
Xserver makes newer PHP versions readily available, so I'd assumed the supporting libraries would be reasonably current too.

But the PHP version and the SQLite library used by PHP's SQLite extension are separate things.
Changing PHP versions does not necessarily update that underlying library.
In my case, switching PHP versions did not solve the problem.

These are the versions I checked in my own Xserver environment in November 2026.
I have not verified that every Xserver server or hosting plan uses the same SQLite version.

A database integration plugin should fail more safely

SQLite Database Integration isn't an ordinary feature plugin in the operational sense.
It replaces the database connection layer WordPress relies on.
If that layer is incompatible with the environment, the site itself may fail to start.

The new requirements are documented in the v3 release notes.
Still, I wish the plugin could check the available SQLite version before an incompatible update is applied.

If the server cannot run the new version, the update should be blocked—or at least fail in a way that doesn't leave WordPress unable to load.

I realise that adding custom pre-update compatibility checks to WordPress's normal plugin update process may not be straightforward.
But for a plugin responsible for database access, the failure path deserves particular attention.

SQLite Database Integration is a WordPress feature plugin intended to help evaluate SQLite support for potential inclusion in core.
That makes its behaviour on existing sites all the more important.

Moving back to MariaDB was harder than expected

Why not just switch back to the MariaDB database I had used before?

Disabling SQLite Database Integration can reconnect WordPress to its previous MySQL or MariaDB database.
But changes made while using SQLite aren't automatically synchronised back to it.
Switching the connection back would mean returning to an outdated copy of the site's data.

I had somehow formed the impression that the two databases were being kept in sync.
That was mistaken.

And while the plugin enables WordPress to run on SQLite, it does not promise a complete round-trip migration between SQLite and MariaDB.

I wanted to avoid writing conversion scripts.
Ideally, I would back up the site with a plugin and restore it into a MariaDB-backed WordPress installation.

I tried several backup and migration plugins, including UpdraftPlus and All-in-One WP Migration.
Some tools advertised SQLite support, but being able to back up SQLite isn't the same as being able to restore that data into MariaDB.
There may also have been compatibility issues related to the SQLite version on my server, although I didn't isolate that as the cause.

In the configurations I tested, I couldn't find a plugin-only route that completed the migration.
The backup might work, but restoring the data into MariaDB didn't finish successfully.

So I exported the SQL and converted it into a form MariaDB could import.

I first checked the converted data against a disposable MariaDB environment, then compared changes made during the migration process.
In the end, I migrated 54 tables, manually disabled the SQLite plugin, and confirmed the connection to MariaDB 10.11.18 in WordPress Site Health.

All I wanted was to change the database back.
Instead, I ended up building GitHub Actions and conversion scripts, repeatedly checking and correcting the results.
It became a much bigger job than I'd expected.

Does that mean SQLite is a bad choice on Xserver?

Not necessarily.
SQLite is still an excellent fit for many small applications, and I continue to like using it.

I also remain happy with Xserver as a hosting service for a conventional WordPress installation using MySQL or MariaDB.

The problem was the combination of a plugin requiring a newer SQLite library and a hosting environment still providing an older one.

Before installing SQLite Database Integration, I would check the SQLite library version actually available to PHP through pdo_sqlite, not just the PHP version.
Even if a plugin version works today, its requirements may change in a future update.

If a hosting plan already includes MySQL or MariaDB, it's also worth asking what you really gain by switching WordPress to SQLite.
I had expected to simplify operations, only to take on a substantial migration later.

Check the exit before choosing the entrance

My biggest mistake wasn't simply overlooking a version number.

I put important data into a system without checking how I would get it out.

Being able to back up a SQLite file and being able to restore its contents into MariaDB are very different guarantees.
Having the data isn't the same as having a straightforward migration path.

The same consideration applies to CMSs, cloud services, and authentication providers.
It's easy to focus on how convenient something is to adopt and overlook what leaving it might require.

I still like SQLite, and I intend to keep using it.
But for a live WordPress site in an environment like mine, I would now hesitate to recommend switching to it.

Getting in can be easy.
Getting out may be another matter.