Wp Sqlite Db Laravel Package

Technical Evaluation

What this actually is. aaemnnosttv/wp-sqlite-db is a WordPress drop-in, not a Laravel package. It ships a db.php file that WordPress auto-loads from wp-content/, replacing the core wpdb class with a SQLite-backed implementation (PDO + a MySQL→SQLite query translation layer inherited from the SQLite Integration plugin). It is configured through WordPress constants (DB_ENGINE, DB_DIR, DB_FILE), not a service provider or config file. There is no composer.json, no namespace, no Laravel package discovery, and no Eloquent driver. Any expectation that this "gives Laravel SQLite support" is a category error — Laravel already has a first-class SQLite connector; this package exists solely to make WordPress run without MySQL.

Architecture fit. Poor for a Laravel codebase directly, and only conditionally relevant to a PHP estate that also operates WordPress. Realistic fit scenarios: (a) a Laravel application that embeds or co-hosts a WordPress instance (marketing site, blog, legacy admin) and wants to eliminate a MySQL dependency in CI or single-node deployments; (b) a local/dev or automated-test environment that needs a disposable WordPress install inside the Laravel repo's tooling; (c) a headless-WordPress-on-Laravel stack where WP is a content store. In all three, the package is infrastructure adjacent to the Laravel app, not part of it. It cannot be wired into Laravel's database.php connections in any supported way, and there is no shared migration path — WP's schema is created by wp-admin/install.php and dbDelta, not Laravel migrations.

Integration feasibility. Technically trivial to install (copy two paths into wp-content/, define three constants, run the installer), which is precisely why it gets adopted without scrutiny — the risk is not in the install, it is in everything after. Feasibility is gated by the query translation layer: WordPress core passes, but plugins and themes that issue raw MySQL (ALTER TABLE ... MODIFY, SHOW TABLES, SQL_CALC_FOUND_ROWS, ON DUPLICATE KEY UPDATE, FULLTEXT, MySQL-only functions, collation-sensitive LIKE) can fail loudly or, worse, silently return wrong results. Feasibility therefore reduces to a plugin-inventory question, not an engineering question.

Technical risk — high.

• Translation fidelity. Emulated SQL is the primary defect class; failures are often silent (wrong collation ordering, ignored index hints, dropped AUTO_INCREMENT semantics) rather than exceptions.
• Concurrency. SQLite is single-writer. WordPress writes on nearly every request (autoloaded options, transients, cron locks, postmeta, session plugins). WAL mode improves reader throughput but does not remove writer serialization; expect database is locked / SQLITE_BUSY under even modest parallel load.
• Single-maintainer, non-Composer distribution. No semantic versioning, no dependency resolution, no security advisory feed. Upgrades are file-replacement events with no diff discipline.
• Upgrade fragility. WordPress core schema changes and dbDelta behavior depend on SHOW/DESCRIBE emulation; a minor WP release can break the drop-in in ways that surface as data corruption, not a clean error.
• Write-permission and hosting constraints. Requires a writable wp-content; incompatible with read-only container filesystems and many managed WP hosts.

Key questions to resolve before any commitment.

1. Do we actually operate WordPress in this estate, and is it production or dev/CI only?
2. What is the concurrency ceiling — is this a single-node, low-traffic site or something that needs horizontal scale?
3. Which plugins are non-negotiable, and have they been smoke-tested against the translation layer?
4. Who owns WordPress core/plugin upgrades, and what is the rollback procedure if a schema change breaks the drop-in?
5. What is the restore path — file copy plus WAL checkpoint, or an existing MySQL-oriented backup plugin that will not understand SQLite?
6. Is the goal "remove MySQL from CI" (low risk) or "run production WordPress on SQLite" (high risk)? These warrant completely different decisions.

Integration Approach

Stack fit. Treat this as out-of-band infrastructure for a WordPress workload, never as a Laravel dependency. Do not add it to the Laravel composer.json, do not attempt to wrap it in a service provider, and do not point Eloquent at the resulting .sqlite file for writes — two ORMs writing the same SQLite file from different processes is a guaranteed locking and integrity problem. If the Laravel side needs WP content, read through the WordPress REST API, or use a read-only corcel-style connection with the explicit understanding that WP's MySQL-flavored schema maps loosely onto SQLite and that Laravel's SQLite driver will not understand WP's index or type conventions.

Migration path. Scope by environment, not by ambition:

• Phase 1 — CI/dev only. Add the drop-in to the WordPress fixture used by Laravel's test suite or local docker-compose. Define DB_DIR/DB_FILE under a gitignored path, bootstrap WP with wp core install, and run the seed/fixture pipeline. Success criteria: deterministic teardown, no MySQL container in the dev stack, reproducible from a clean checkout. This is where the package earns its keep.
• Phase 2 — staging parity. Only if Phase 1 succeeds, stand up a staging WP instance on SQLite with the full production plugin set and run the plugin smoke suite plus a realistic write workload (comment submission, cron, admin saves). Measure SQLITE_BUSY rates and p95 admin latency against the MySQL baseline.
• Phase 3 — production. Gate on evidence, not enthusiasm. Required: concurrency benchmark at 2–3× expected peak, confirmed backup/restore drill, documented per-plugin test results, and an owner for WP core upgrades.

Compatibility. Verify PHP 8.x with pdo_sqlite/sqlite3 extensions, the specific WP major version, and the SQLite library version (translation behavior has shifted across SQLite releases). Pin the drop-in by commit SHA in the repo or container image — there are no version constraints to lean on. Verify behavior on the target filesystem: WAL mode requires shared-memory support, which some container/network mounts do not provide.

Sequencing. Install drop-in → install WP → inventory plugins → run translation-gap test suite → benchmark writes → backup/restore drill → upgrade rehearsal (WP core + drop-in bump) → only then production. Budget the upgrade rehearsal as a recurring quarterly task, not a one-off.

Operational Impact

Maintenance. The artifact is tiny; the maintenance surface is not. Two files under version control, but the behavioral contract is "MySQL compatibility," which means every WP core update and every plugin update is a potential regression. No changelog discipline or LTS commitment should be assumed. Maintenance cost lands on whoever owns WordPress, and that ownership must be named before adoption.

Support. Community-only: GitHub issues and a single primary maintainer. No vendor, no SLA, no security advisory channel. For a production dependency this is the dominant risk; for a CI fixture it is acceptable. The underlying translation layer is also downstream of the WordPress sqlite-database-integration effort, so upstream changes can arrive unannounced.

Scaling. Vertical only, single node. No read replicas in the MySQL sense (file copies are snapshots, not replicas), no connection pooling, no managed failover. Effective concurrency is bounded by write serialization; read-heavy traffic is fine under WAL, write-heavy traffic (WooCommerce, membership, form submissions, comment-heavy blogs) is not. Database size is bounded by local disk and by the practicality of file-based backup — large postmeta tables and transients make the file grow and slow.

Failure modes and detection.

• SQLITE_BUSY / "database is locked" under concurrent writes → surfaces as 500s or silently dropped writes; alert on PHP error logs and on 5xx rate.
• Silent wrong query results from translation gaps → surfaces as content or ordering anomalies; needs fixture-based regression tests, not monitoring.
• Extension missing or filesystem read-only after a container rebuild → WP fails to bootstrap entirely; catch in deploy smoke test.
• Corrupted DB file after an ungraceful shutdown → requires a tested restore procedure; WAL/SHM files must be included in backups.
• Plugin or WP core update breaking schema assumptions → detect via staging rehearsal and a post-deploy smoke suite.
• Unbounded file growth from transients/cron → periodic cleanup and size alerting.

Ramp-up. Installation ramp-up is an afternoon. Operational ramp-up is weeks: a team must learn where MySQL semantics leak (collation, AUTO_INCREMENT, index behavior, ON DUPLICATE KEY), how to inspect the SQLite file directly, and how to distinguish "plugin is broken" from "translation layer is broken." Debugging requires SQLite fluency that most WordPress teams do not have. Recommend a single named owner, a written runbook (backup, restore, upgrade, rollback), and an explicit statement in the architecture decision record that this is a scoped exception for WordPress workloads — not a precedent for using SQLite as a system of record in the Laravel platform.