What started as a simple plugin switch ended up revealing something much more interesting: WordPress doesn’t have to behave like a traditional CMS tied to a database server. With SQLite, it starts behaving like a portable, self-contained system—almost like a container image, just without the overhead.
The original motivation wasn’t speed, and that’s important. Performance between the SQLite Database Integration and the WP SQLite DB driver is roughly comparable in real-world usage. One might edge out slightly in micro cases, the other is more consistent in complex scenarios, but none of that is the real story.
The real advantage is portability.
With MySQL, every WordPress site is split into two layers: files and database. Moving a site means exporting, importing, fixing credentials, dealing with host differences, and hoping nothing breaks along the way. It’s friction baked into the architecture.
SQLite removes that split entirely. The database becomes just another file sitting inside `wp-content/`. Copy the folder, and you’ve copied the site—data included. No separate service, no credentials, no migration ceremony. It’s a fundamentally different operational model.
That changes how you build and deploy sites.
Instead of installing WordPress from scratch every time, configuring plugins, tweaking settings, and repeating the same setup over and over, you can create a “preset” site. A fully configured baseline. From there, launching a new site becomes a simple act of duplication: copy the folder, adjust the URL, and you’re live. It feels less like installing software and more like cloning an environment.
At that point, WordPress starts to resemble a containerized system in practice. You have a base image (your preset site), instances (your cloned sites), and configuration overrides (`wp-config.php`). You’re not using Docker, but you’re thinking in the same way: immutable base, fast replication, minimal setup.
And that’s where the choice of driver starts to matter again—not for speed, but for predictability.
The older WP SQLite DB driver is simple and proven, but it relies on lighter query translation techniques that can behave inconsistently in edge cases. The newer SQLite Database Integration takes a more structured approach, using a proper SQL parser and aligning with the direction WordPress core is moving toward. It’s not dramatically faster, but it is more reliable over time.
And when your workflow depends on cloning sites and reusing environments, reliability compounds. You don’t want one instance behaving slightly differently because of a subtle query mismatch. Predictability becomes the real performance metric.
The natural conclusion isn’t to rush every site into SQLite or migrate everything immediately. It’s to recognize what SQLite enables: a shift from managing WordPress installations to deploying WordPress instances.
Once you see it that way, the appeal becomes obvious. One folder. One database file. Copy, adjust, run.
Not quite static. Not quite traditional CMS.
But something in between that fits surprisingly well with modern workflows.