SQLite Database Integration

Changelog

3.1.1

• Support date arithmetic with INTERVAL operators (#539)
• Fix ROLLBACK as the first transaction of a connection (#537)
• Fix matching a foreign key reference to a unique key with a different case (#534)
• Fix FOUND_ROWS() without SQL_CALC_FOUND_ROWS (#533)
• Fix unique keys and foreign key restore without stringified fetches (#532)
• Fix CREATE TEMPORARY TABLE IF NOT EXISTS and DROP TEMPORARY TABLE as the first temporary table (#524)
• Fix a warning for a foreign key referencing a table with a shorter unique key (#523)
• Fix temporary table lookup without stringified fetches and with a different case (#522)

3.1.0

SQLite Database Integration 3.1 is here! 🎉

This release improves database storage and configuration and fixes several MySQL compatibility issues.

What’s new

Version 3.1 improves how WordPress sites store, locate, and protect their SQLite databases. It also fixes SQL behavior and export compatibility:

• Randomized database paths: The default database location is now a randomized directory under wp-content/database/, recorded in wp-content/database/db-path.php. (#502)
• DB_PATH: Configure the database with one full-path constant, also available at runtime for integrations. (#512)
• SQL compatibility: Fix IF() condition evaluation and make TRADITIONAL enable its component SQL modes. (#518, #509)
• WordPress table collations: Default to utf8mb4_unicode_520_ci for new tables created with WordPress’s charset settings, improving exports to MariaDB. Existing tables keep their recorded collation. (#514)
• Documentation: A new plugin README and expanded FAQ explain database storage and secure configuration. (#520)

For more information about database paths and secure configuration, read the database storage guide.

Upgrading to 3.1

Upgrading an existing SQLite site is straightforward:

1. Back up your SQLite database.
2. Update the plugin to version 3.1.

Existing .ht.sqlite and .ht.sqlite.php databases move to the randomized layout automatically unless a database file path is explicitly configured.

To properly secure the database, set DB_PATH in wp-config.php to an absolute file path outside the web root that your web server does not expose. Its directory must be writable by PHP. Changing DB_PATH does not move an existing database.

Breaking changes

Review these changes if you use custom database settings or integrations:

• Database paths: Default database files now move to randomized paths under wp-content/database/. Explicitly configured file paths stay unchanged. Integrations, including backup and migration tools, must read DB_PATH after WordPress loads instead of assuming a fixed filename.
• Legacy constants: DB_DIR and DB_FILE are now deprecated. They and the previously deprecated FQDB and FQDBDIR remain supported, but DB_PATH takes precedence. Conflicting values trigger warnings.
• Absolute paths: Relative database file and directory paths are now rejected. :memory: remains available for in-memory databases.

Thank you

Thank you to everyone who contributed, tested, and helped update integrations.

Changes since 3.0.2: v3.0.2...v3.1.0

3.0.2

• Fix schema reconstruction with native numeric results (#506)
• Fix lexer edge cases and string handling (#505)
• Preserve index prefix lengths and order in SHOW CREATE TABLE primary keys (#500)
• Align savepoint handling with MySQL semantics (#496)

3.0.1

• Mark the plugin as compatible with WordPress 7.1 (#497)
• Fix fresh multisite database setup (#492)

3.0.0

SQLite Database Integration 3 is here! 🎉

This release introduces an all-new SQLite database driver for WordPress, rebuilt from the ground up. Its purpose-built MySQL lexer, parser, and emulation layer deliver broader compatibility, more accurate behavior, and a stronger foundation for future improvements.

The 3.0 release spans nearly two years of work, featuring 160 pull requests and 1,075 commits from 15 contributors.

What’s new

The new driver advances SQLite support for WordPress, plugins, database tools, and other MySQL-based applications. These improvements include:

• New SQL engine: The pure-PHP lexer and parser provide extensive coverage of the official MySQL grammar.
• Broad query support: Complex joins, subqueries, CTEs, unions, and other advanced queries are now supported.
• Schema emulation: WordPress and database tools can query emulated MySQL INFORMATION_SCHEMA tables.
• Schema introspection: SHOW and DESCRIBE statements provide accurate MySQL-like metadata.
• Improved data handling: Types, casts, defaults, auto-increment, values, and escaping better match MySQL.
• Refined MySQL semantics: Better emulation of SQL modes, variables, functions, transactions, and errors.
• Better concurrency: Write-ahead logging and fewer locks reduce blocking between readers and writers.
• PDO API: The new driver implements the PDO MySQL API, supporting many MySQL-based tools and applications.
• Extensive testing: Test suites cover parsing, translation, metadata, concurrency, PDO, and end-to-end workflows.

For more information about the new driver and its architecture, read the driver announcement.

Modular design

The project was redesigned as a set of focused packages, separating the core driver from its WordPress integration:

• SQLite Database Integration: The WordPress plugin powered by MySQL on SQLite.
• MySQL on SQLite: A standalone PDO MySQL drop-in for running MySQL-based PHP applications on SQLite.
• MySQL proxy (experimental): A MySQL wire protocol bridge to PDO-compatible drivers for clients outside PHP.

This architecture opens the driver to new integrations, applications, and development tools beyond WordPress.

Upgrading to 3.0

Upgrading an existing SQLite site is straightforward:

1. Back up your SQLite database.
2. Update the plugin to version 3.0.

On first connection, the new driver automatically initializes its metadata without changing your tables or content.

If you used the new driver preview, you can now delete the WP_SQLITE_AST_DRIVER flag.

Breaking changes

Most WordPress sites need no changes. Review the following if you use a custom setup:

• New driver:
  • The new driver is always used. The legacy driver was removed.
  • The WP_SQLITE_AST_DRIVER feature flag was removed.
• Updated SQLite version requirements:
  • SQLite 3.37.0 or newer is required.
  • The WP_SQLITE_UNSAFE_ENABLE_UNSUPPORTED_VERSIONS opt-in enables limited SQLite 3.27.0–3.36.x support.
• DB_NAME is required:
  • It must be defined and non-empty.
  • It is used dynamically, independently of the SQLite file name and stored metadata.
• SQLite defaults have changed:
  • Journal mode now defaults to WAL. Account for -wal and -shm sidecar files.
  • Synchronous mode now defaults to NORMAL in WAL mode.
• Updated configuration constants:
  • DATABASE_ENGINE was removed. Use DB_ENGINE.
  • DATABASE_TYPE is deprecated. Use DB_ENGINE.
  • FQDBDIR is deprecated. Use DB_DIR.
  • FQDB is deprecated. Use DB_DIR and DB_FILE.
• Updated driver classes:
  • WP_SQLite_Driver is deprecated. Use WP_MySQL_On_SQLite.
  • WP_PDO_MySQL_On_SQLite was replaced by WP_MySQL_On_SQLite.
  • WP_SQLite_Driver_Exception was replaced by WP_MySQL_On_SQLite_Exception.
  • WP_PDO_Proxy_Statement was replaced by WP_MySQL_On_SQLite_Statement.
• Sunsetting $GLOBALS['@pdo']:
  • Injecting a PDO connection through $GLOBALS['@pdo'] is no longer supported.
  • Reading $GLOBALS['@pdo'] is deprecated. Use $wpdb->get_driver()->get_sqlite_pdo().
• Renamed driver constructor options:
  • pdo → sqlite_pdo.
  • journal_mode → sqlite_journal_mode.
  • synchronous → sqlite_synchronous.

Thank you

Thank you to everyone who helped build, test, review, and improve the new driver. Your work made this possible.

3.0 milestone: 160 pull requests

Changes since 2.2.23: v2.2.23...v3.0.0

2.2.23

• Add Query Monitor 4.0 support (#357)
• Translate MySQL CONVERT() expressions to SQLite (#356)

2.2.22

• Support INSERT without INTO keyword (#354)
• Add tests for MySQL row-level locking clauses (#342)
• Improve automated deploy setup.

2.2.21

• Monorepo setup + release automation (#334)
• Rework release workflow (#350)
• Fix incorrect PHP polyfill implementations (#338)