I recently made one of the biggest behind-the-scenes improvements to my website since it went live. It's not flashy, it doesn't change the design, and visitors will never notice it. But from a long-term maintenance and portability standpoint, it is a massive win.
For as long as WordPress has existed, it has depended on MySQL, or MariaDB if you want drop-in compatibility. This has always been fine right up until you need to move a site.
If you have ever migrated a WordPress install, you know the two usual options.
The first is to zip up your files, move them to a new server, then spend the next several hours or days dealing with the database. Sometimes you get lucky and the environments are similar enough that the migration mostly works. More often, you end up fixing serialized data, broken paths, collation issues, or subtle differences in configuration that only show up once real traffic hits the site.
The second option is to pay for a migration plugin or service that does the heavy lifting for you. These can work well, but they are expensive, opaque, and still leave you dependent on MySQL behaving nicely on both ends.
Neither of these options feels great, especially for a site that is otherwise easy to move.
Enter SQLite
WordPress is in the process of adding official support for SQLite. It is not merged into core yet, but it already works today via a plugin and is expected to land in core within the next year or so.
SQLite flips the traditional database model on its head. Instead of running a separate database server, the entire database lives in a single file. In WordPress’ case, that file sits in wp-content/database.
There is no database daemon to configure. No users to create. No host-specific quirks. It is just a file.
That one change fundamentally alters how portable a WordPress site can be.
Why This Matters So Much
With SQLite in place, moving my site is almost trivial.
I can zip up the entire site, move it to a new server, unzip it, and the site is effectively ready to go. The only remaining step is updating DNS so my domain points to the new location.
No database exports. No imports. No search and replace passes across the database. No hoping that the new host’s MySQL configuration matches the old one closely enough.
Because SQLite is not tied to a specific environment, it behaves the same everywhere.
What Lives in My Monorepo (and What Doesn’t)
At this point, almost everything that defines my site lives inside a single monorepo.
That includes the SQLite database file, which in my case is small, under 9 MB, the source code for my WordPress theme, which handles all functionality and features, and the Next.js site that visitors actually see.
There are only two things that are intentionally not included.
Media is stored externally in Cloudflare R2, which keeps large binary assets out of the repository entirely. That alone removes a huge amount of noise and bloat from backups and version history.
Plugins are handled a little differently. I do not commit plugin code directly. Instead, I have a script I run locally that copies my WordPress theme from my PhpStorm project into the monorepo, pulls in the current SQLite database, and generates two key files: a plugins/manifest.json and a sanitized wp-config.php.
The manifest lists every installed plugin along with its title, author, version, and source URL. The wp-config contains only the constants my site's features actually need, with all sensitive data like credentials and secrets being stripped out by the script.
In other words, the repository knows exactly which plugins are in use and what configuration the site expects, without needing to vendor plugins or expose sensitive values. Rebuilding the site elsewhere becomes a matter of restoring the repo, reinstalling the listed plugins, supplying actual credentials, and pointing DNS to the new server.
Versioning the Entire Site State
The result is that my content, theme logic, frontend, and plugin configuration all live together in one place.
If I need to roll back, move hosts, spin up a new environment, or rebuild everything from scratch, I can do so from a single source of truth. There is no separate database backup to track down and no mystery about which plugins were installed at the time.
It is not quite infrastructure as code, but it is surprisingly close.
The One Real Drawback
The only real downside is the initial migration from MySQL to SQLite. It is not hard, but it is a little annoying, and it is not something you want to do casually on a large or highly dynamic site.
That said, once it is done, you are done.
From that point forward, the setup is remarkably simple and robust.
Why This Feels Like a Big Win
This change is not about performance tweaks or shiny new features. It is about reducing complexity and future headaches.
WordPress has always been easy to install, but surprisingly hard to move cleanly. SQLite finally brings those two things into alignment.
For me, this feels like future-proofing in the best sense of the word. Fewer moving parts, fewer hidden dependencies, and a site that I can pick up and relocate without dread.
Sometimes the best improvements are the ones you hope you never have to think about again.
February 5, 2026
I want to add an important clarification.
This is not something I would recommend for everyone.
SQLite is an excellent fit for my site, but that is largely because of what my site is and, just as importantly, what it is not.
When SQLite Makes Sense
If you are running a small, personal site and you do not see it becoming anything more than that, SQLite is absolutely worth considering.
A personal blog. A writing site. A portfolio. A mostly static site with occasional updates. In these cases, SQLite’s simplicity is a genuine advantage. Fewer moving parts means fewer things to break, fewer migrations to dread, and a site that is easy to back up, restore, and relocate.
That is the category my site falls into, and it is unlikely to ever leave it.
Where the Trade-Offs Start to Matter
Once you start thinking about scale, the story changes.
If you plan to add a shop, a heavily used comments section, or a large number of interactive features, SQLite becomes a much harder sell. The same applies if you are running a multi-author blog with frequent posts throughout the day and constant activity in the admin.
The core issue is architectural.
MySQL and MariaDB run as services. They live in memory, manage their own processes, and are always available to the application. WordPress can communicate with them quickly and efficiently, even under sustained load.
SQLite, on the other hand, is a single file. Every read and write goes through that file. For low-traffic or mostly read-only workloads, this is fine. Under heavier concurrent writes, it becomes a bottleneck.
That does not mean SQLite is bad. It just means it has a lower ceiling.
Why That Ceiling Doesn’t Matter for Me
In my case, I am never going to hit it.
My site is headless, heavily cached, and only revalidates when I update content in WordPress. Even then, it only revalidates what actually needs to change. Most visitors never touch WordPress or its database at all.
From SQLite’s perspective, the workload is tiny.
So while the theoretical limits are lower than MySQL’s, they are still far above anything my site will realistically demand.
A Recommendation, Not a Rule
If you are building a minimalist WordPress site for yourself and you do not expect it to grow into a platform with constant interaction, SQLite is something I would genuinely recommend looking into.
If, however, you are building something larger. A publication with multiple authors. A community with active comments. A site with commerce or frequent writes. Then no, I would not recommend it. In that case, MySQL or MariaDB remains the better, safer choice.
This is not about which database is “better” in the abstract. It is about choosing the right tool for the job and the future of the site you are building.
SQLite works beautifully for my needs. It just happens that my needs are very specific.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.