SQLite or MySQL? SQLite's Own Authors Say You Probably Need Less Than You Think

Nearly every self-hosted PHP business app now ships with the same choice at install time: SQLite for a quick trial, MySQL or MariaDB for production. Our own product pages say exactly that.

And nearly every guide on the internet resolves it the same reflexive way: use MySQL, SQLite is for testing.

That advice is usually wrong for a small business app, and the people who wrote SQLite say so more clearly than we could.

What SQLite's own documentation says

From sqlite.org's "Appropriate Uses For SQLite" (read 2026-08-01), quoted verbatim:

"SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites)… Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic."

One hundred thousand hits a day, described by its own authors as conservative.

For context: a rota used by fifteen staff, a leave tracker for forty people, an equipment log for one office, a petty-cash ledger. These are not hundred-thousand-hit-a-day systems. They are hundred-hit-a-day systems, and often less.

The real limitation, stated precisely

SQLite's constraint is not size and it is not speed. It is writers:

"SQLite supports an unlimited number of simultaneous readers, but it will only allow one writer at any instant in time."

And the documentation's own guidance on when that matters:

"If many threads and/or processes need to write the database at the same instant (and they cannot queue up and take turns) then it is best to select a database engine that supports that capability… SQLite only supports one writer at a time per database file. But in most cases, a write transaction only takes milliseconds and so multiple writers can simply take turns. SQLite will handle more write concurrency than many people suspect."

"More write concurrency than many people suspect" is the sentence the reflexive advice ignores. A write that takes milliseconds means dozens of people can be saving records in the same minute without ever colliding.

So when should you actually choose MySQL?

The documentation gives the honest test:

"if the website is write-intensive or is so busy that it requires multiple servers, then consider using an enterprise-class client/server database engine instead of SQLite."

Translated for a small business app, choose MySQL/MariaDB when any of these is true:

Many people write at the same instant, continuously — a till taking sales on four registers at once, a booking page with real concurrent public traffic.
You need more than one server, or plan to.
You want the database accessible outside the app — reporting tools, another application, a BI dashboard connecting over the network. SQLite is a file; MySQL is a service, and that difference is the point.
Your host backs up MySQL automatically but not arbitrary files — a genuinely practical reason, and one worth checking.
You already run MySQL and adding a second storage type is just more to think about.

And choose SQLite when:

A handful of staff use it internally. Which describes most of the tools in this catalogue.
You want the whole system to be a folder. Backup is copy the file. Migration is copy the file. There is real operational value in a database you can email to yourself.
You do not want to create a database, a user, and remember to attach them — the step that causes more failed installs than anything else.

The honest wrinkle about backups

This cuts both ways and most articles only give you one side.

SQLite is easier to back up — one file, copy it, done. But copy it while a write is in progress and you may capture a torn state. The safe method is the .backup command or VACUUM INTO, not cp. If your backup is a nightly file copy of a busy database, use MySQL and mysqldump instead.

MySQL is harder to back up and better supported by hosting panels. cPanel's backup tools understand MySQL databases natively; they treat your SQLite file as just another file, which is fine — provided the file copy is safe.

For a low-write internal tool backed up nightly at 3am, a file copy is realistically fine. For anything busier, it is not. That, and not raw performance, is the most common practical reason to pick MySQL for a small app.

Our own pages, and the tension in them

You will notice our product FAQs say things like "SQLite for a zero-config trial, MySQL/MariaDB for production on ordinary shared hosting."

That framing is conventional and slightly conservative, and the primary source above is the better guide. For a fifteen-person rota or a forty-person leave tracker, SQLite is not a trial mode — it is a legitimate production choice, and it removes an entire class of installation failure.

We are pointing at the primary source rather than our own wording because that is what we would want a vendor to do.

How to switch later, if you need to

You are not locked in. The path is standard and unexciting:

Export from SQLite — most apps offer a CSV export per entity, which is the simplest route, or use a schema/data dump tool.
Create the MySQL database (and remember to attach the user to it — the classic failure).
Point the app's config at MySQL and re-run its installer or import.
Verify record counts match before you delete anything. Count the rows in both. If the numbers disagree, stop.
Keep the old SQLite file for a month.

Budget an evening, not a week — and do it before you are busy, not during.

The short version

SQLite handles far more than its reputation suggests, and the number comes from its authors: "fewer than 100K hits/day should work fine," described as conservative.

Choose MySQL if many people write at once continuously, you need more than one server, something outside the app must read the database, or your backup story is a naive file copy of a busy file.

Choose SQLite for internal tools used by a handful of staff — which is most small business software. Fewer moving parts, fewer install failures, and a database you can copy like a document.

And do not let "MySQL is for production" decide it for you. It is a habit, not a threshold — the threshold is published, and you are almost certainly nowhere near it.

Next steps

Installing a PHP app on cPanel — the click path — includes the database step this guide lets you skip
Your backup is not a backup until you have restored it
Self-hosted software by category — most products run on either
A concrete both-drivers example: Vendra installs on SQLite for a zero-config trial and on MySQL for production, through the same installer

Every quotation above is from SQLite's own documentation, linked and dated. Where our product pages and the primary source differ in emphasis, we have said so and pointed you at the primary source.