Most WordPress sites today still rely on MySQL or MariaDB as their database backbone. For years, that’s just been the “normal” way of doing things. But we’ve been experimenting with something different — bringing SQLite into the mix and pushing it even further with custom sharding strategies, all while writing our own plugins to glue it together.
This isn’t just about making WordPress run on SQLite. It’s about rethinking how the database layer of WordPress can scale, stay portable, and even become blazing fast for certain workloads.
Why SQLite?
SQLite is lightweight, self-contained, and requires no server daemon. For developers, it means you can drop your WordPress install onto almost any environment without the overhead of spinning up MySQL. For self-hosters, it means a simpler stack with fewer moving parts.
But SQLite isn’t known for handling huge, busy sites. That’s where our sharding experiment comes in. Instead of relying on a single .sqlite file, we split the workload across multiple shard files (six in our current setup). Each shard handles its own set of tables or site responsibilities.
The result? Faster queries, less file contention, and the ability to scale out WordPress in ways most developers haven’t tried.
Custom Plugins for Sharding
To make this work, we’ve been developing custom plugins that:
- Hook into WordPress’s database layer (
db.phpdrop-ins) to manage which shard handles which query. - Automatically attach databases at runtime so WordPress thinks it’s one giant logical DB.
- Provide tools to inspect, maintain, and repair shards if anything goes sideways.
We’ve even experimented with manual shard creation scripts so site owners can choose how many shards they want from the very beginning.
AI as a Development Partner
Here’s where things get really interesting: AI has been a co-developer in this project.
- It has helped troubleshoot thorny PHP and Docker issues that would have taken hours (or days) to untangle.
- It has suggested improvements to our sharding logic, flagging places where permissions, ownership, or SQL parsing could break.
- It has helped us package the system into ZIP-ready plugins and Docker images so others can test this without digging deep into configs.
Looking ahead, AI could become a testing assistant, running through automated shard stress-tests, benchmarking performance under different workloads, or even analyzing query logs to recommend shard layouts.
Why This Matters for the Future of WordPress
For self-hosted WordPress projects, this kind of experimentation could open new doors:
- Portability: A fully sharded SQLite WordPress can be copied like a flat-file CMS, yet scale like a database-driven site.
- Performance: Sites with tens of thousands of readers could use sharding to handle heavy front-page loads without needing a managed SQL cluster.
- Resilience: Shards can isolate problems — if one shard corrupts, the others keep the site alive.
- Simplicity: A single archive could contain your whole site, database and all, ready to run anywhere.
In many ways, this feels like a glimpse into what the next generation of self-hosted WordPress could look like: lightweight, AI-assisted, and built for modern speed.
What’s Next
Our six-shard prototype is just the beginning. We’re experimenting with different shard counts, dynamic shard allocation, and the idea of multi-region shard syncing so a WordPress site could have US, UK, and AU readers hitting local SQLite shards — all unified under one site.
The journey hasn’t been easy, but with AI at our side, the process has been faster, smarter, and way more exciting than doing it alone.
This is just the start. WordPress has always been about empowering creators — and maybe, just maybe, sharded SQLite with AI-driven tooling is how we empower the next wave of self-hosters.
About the Author
