Small Restaurant Site SQLite Benchmark

Headline Result

When the LALR parser is actually wired into the request-time SQLite driver path, SQLite WAL+LALR is slower than MySQL 8.4 InnoDB in every workload and concurrent-request cell in this small restaurant benchmark.

• SQLite had 0 failed flows, 0 write verification failures, and 0 SQLite lock/busy log events, but it did emit PHP warning/database-error log events in every measured SQLite row. The result should be read as an adapter/translation regression, not clean LALR parser performance.
• At write-heavy concurrency 4, SQLite completed 5.86 median flows/s with p95 1.98s; MySQL completed 106.20 median flows/s with p95 98ms.
• In the c4 read-heavy SQLite row, all measured HTTP responses were 200s, but the server logged 763 PHP warning/database-error events. Public page browsing stayed near 48ms p95 and REST/XHR near 164ms p95, while admin_read jumped to about 2.01s p95.
• The request log for that same row shows 1.87s wall-time p95 but only 10.6ms database-time p95. The extra time is PHP/driver/parser/translation/error-handling work around the query, not SQLite engine time.
• The PHP logs show malformed translation for WordPress INSERT ... ON DUPLICATE KEY UPDATE option/transient writes, including wp_styles_for_blocks, plus an @@SESSION.sql_mode compatibility warning.
• The measured SQLite PHP-FPM pools contained env[WP_SQLITE_USE_LALR_PARSER] = 1. WAL setup returned wal from PRAGMA journal_mode=WAL.
• The combined benchmark branch was 94b33a7cc426ce81ad573e561dedbf67d33a3def, including the local adapter fix for SELECT @@SESSION.sql_mode.

How The Test Was Conducted

1. Create the same small restaurant WordPress fixture for MySQL 8.4 InnoDB and SQLite: homepage, menu, reservations, contact, about, event/catering/gallery/location/journal pages, six posts, seed comments, seed reservations, and benchmark users.
2. Before every measured cell, restore that variant's clean database snapshot so previous writes do not affect the next run.
3. Start local nginx and PHP-FPM for the case, log in worker admin sessions outside the measured timing window, and run a warm-up for 5.0 seconds.
4. Measure for 20.0 seconds with the configured concurrent-request count.
5. Read-heavy flow mix: public page/menu/search/REST reads plus a small amount of logged-in wp-admin reads.
6. Balanced and write-heavy mixes add verified comment writes, public reservation-request writes, and authenticated editor-save simulations.
7. Record full-flow latency, average request completion time, throughput, write throughput, failures, write verification, SQLite WAL size, and SQLite lock/busy logs.