3 ms·
The theoretical answer is because SQLite is not the right tool for the sort of things Wordpress does. SQLite supports more concurrency than one might expect fro
by glurgh 13y ago
The theoretical answer is because SQLite is not the right tool for the sort of things Wordpress does. SQLite supports more concurrency than one might expect from an embedded db - it's still an embedded db, though. Writing, for instance involves a database-global lock.
The practical answer is - Wordpress is written in a MySQL-specific way. It doesn't officially support, say, Postgres or Oracle either.
- masklinn 13y ago> The theoretical answer is because SQLite is not the right tool for the sort of things Wordpress does. Which probably isn't true. SQLite is bad at concurrent writes. Your average wordpress install is almost only reads. And with 3.7.0's WAL, readers and writers don't block one another anymore.
- glurgh 13y agoThe trouble is that there are many, many Wordpress sites out there that are not an average Wordpress install. People (disturbingly) write e-commerce sites on top of Wordpress. SQLite is not the right tool for the sort of things Wordpress does not because you couldn't write a blogging tool using SQLite but because Wordpress is crazy.
- jeltz 13y agoIf one could write blogs and ecommerce sites using MyISAM (shrudders) then why wouldn't SQLite work? MyISAM had -- at least in theory, I have not done any benchmarks -- even worse concurrency than SQLite.
- glurgh 13y agoI hope I've completely forgotten any details of the convoluted locking behaviours and tuning options of MyISAM (which, in my head at least, is read as 'miasma') but they were there to at least attempt to support certain types of concurrency. And they were table-level whereas the SQLite write lock is db-wide. Could you reasonably write blogging software that uses SQLite? Sure. It's just that Wordpress isn't that blogging software - it's written to be paired with MySQL, for good or ill.
- jeltz 13y agoMyISAM has reader/writer table locks[1] which meant that nobody could read while someone was writing to a table. SQLite can be ran in two modes 1) database reader/writer lock or 2) in WAL mode[2] where readers do not block writers and writers do not block readers. Writers block each other though so there can only be one concurrent writer. WAL mode provides concurrency superior to what MyISAM did. 1. The locks could sometimes be bypassed by inserts, but not reliably so. 2. http://www.sqlite.org/wal.html
- glurgh 13y agoSure but WAL in SQLite is 3 years old. Wordpress is 10 years old. MySQL with MyISAM is a lot older than that. I personally happen to think almost everything about Wordpress is wrong. It's just hard to blame them they didn't start or subsequently adopt SQLite. I doubt it's ever been as much as on their radar.
- emn13 13y agoI believe you can approximate table-level locks in sqlite by splitting your database into multiple files. Transactions across multiple databases are atomic (provided you don't use WAL), so you're still in a fairly safe place. However, I'm not sure how practical it is to split a database into lots of files; or whether the sqlite engine deals efficiently with queries that span many databases, for instance - I've never actually done this. But if you really need a particular table to be writable without locking the rest of the database, it's probably a fairly decent workaround.
- jeltz 13y agoAgreed, and I do not think the lack of SQLite support in Wordpress has anything to do with what SQLite can or cannot do. Only that it was written by LAMP developers who do not care for databases other than MySQL.
- deleted 13y ago[deleted]
- deleted 13y ago
- mikeash 13y agoGiven how easy it is to install Wordpress such that it will fall over at the slightest breeze of traffic, and it appears to be installed that way by default, it's hard to see SQLite making things any worse. Maybe it wouldn't handle crazy situations out of the box, but WP is already in that situation anyway.