SQLite as a WordPress Database: Current Status, Limitations, and Use Cases

Understanding WordPress and SQLite Properly

WordPress does not currently support SQLite as a standard database platform that can be selected in the core. The official system requirements still list MySQL or MariaDB; SQLite is not one of the standard requirements for a WordPress installation. Therefore, anyone running WordPress with SQLite does not simply change a core setting but instead adds a custom integration layer to WordPress.

This layer is provided by the plugin SQLite Database Integration Ready. It is available in the WordPress.org plugin directory and is being developed as a community or feature plugin. Its goal is to test an SQLite implementation and gather feedback for possible future integration into the core. Its presence in the WordPress.org ecosystem does not, therefore, constitute approval as a standard component of a typical WordPress installation.

This initiative has been in the works for some time: In September 2022, a public proposal was made within the WordPress Core Team to officially support SQLite in the long term. Since January 2023, the implementation has been available as a standalone plugin; the reference to Performance Lab at that time described a development milestone, not the standard approach for every WordPress website today.

For a reliable classification, the version number is key. As of the research date, October 18, 2026, v3.1.0, released on October 8, 2026, is the stable release version. Features from the development branch should not automatically be considered characteristics of this stable version. Conversely, it would be incorrect to equate the active plugin with a general production release for every WordPress use case solely on that basis.

Therefore, the answer to the reader’s question is “yes,” but only to a limited extent: SQLite can be a good choice for clearly defined installations, such as for development, demos, or small single-server websites with manageable changes. For distributed, write-intensive, or business-critical installations, MySQL or MariaDB remain the officially supported and generally more suitable foundation. The decisive factors are the architecture, write patterns, and the actual compatibility of the stack being used.

File database, drop-in, and SQL compatibility

The fundamental difference lies in the storage model. SQLite is a File Database: The data is stored locally in a database file on the file system. MySQL and MariaDB, on the other hand, operate as standalone database services with which WordPress communicates via a server connection. SQLite can therefore provide a more streamlined environment, but it requires a suitable local storage location and appropriate file permissions.

WordPress Core, themes, and most plugins use the well-known interface for database access wpdb. The plugin replaces the standard database layer with the drop-in wp-content/db.php. This drop-in intercepts queries and acts as an intermediary between the expected MySQL-based WordPress environment and SQLite. As a result, the application interface remains the same for many components, even though the underlying database changes.

The middleware layer is the key factor behind the simplified statement „WordPress runs on SQLite.“ WordPress does not automatically generate SQLite-specific SQL. The project documentation in the development branch trunk Describes a MySQL parser that emulates the SQL syntax and the functions required for SQLite. This explains the development approach, but it is neither a commitment to a stable release nor a guarantee that every individual MySQL query or extension will be compatible without modification.

You should examine extensions particularly carefully if they generate SQL directly, rely on database functions, or manage their own tables in an unusual way. This also applies to importers, reporting tools, and maintenance scripts. A theme or plugin may function normally under standard conditions but could still fail during a rare administrative task, an update, or a specific query due to an unaccounted-for MySQL quirk.

The differences in schema, metadata, and typical queries remain relevant for the evaluation. The internal overview of WordPress Database Tables and Their Performance helps identify database-intensive extensions and custom tables as potential checkpoints. SQLite Integration This does not replace an analysis of such queries, nor does it relieve you of the responsibility to test any customizations made outside the standard WordPress interface before deployment.

When SQLite Is Technically Feasible

A sound decision cannot be based on a general estimate of visitor numbers. What matters is the Writing Contest: SQLite allows multiple concurrent readers, but only one write operation can occur at a time per database file. If write operations occur simultaneously, subsequent write operations must wait. The SQLite documentation recommends using a client-server database when there are many independent clients, multiple computers, or many concurrent write operations.

Clearly defined use cases include local development, training sessions, demos, and short-lived test environments. In these scenarios, there’s no need to set up a separate MySQL or MariaDB service, while the plugin and theme stack can be tested in a controlled manner. Even a small website on a single server can be suitable if it is primarily read-only and editorial changes are infrequent and do not occur in concentrated bursts.

However, a simple company website, a personal blog, or a campaign page isn’t automatically suitable. Contact forms, member areas, newsletter integrations, or custom-programmed endpoints can trigger additional write operations. Therefore, don’t just check page views—also monitor updates to settings, form submissions, scheduled tasks, and data changes caused by plugins and external interfaces.

For online stores that handle orders, booking and ticketing systems, active communities, or applications with many AJAX and REST write operations, this limitation is usually more significant. In such scenarios, multiple users can save orders, change availability, or create posts nearly simultaneously. Having multiple web servers behind a load balancer is also incompatible with the local file-based approach that SQLite requires for this use case.

Caching serves a different purpose than SQLite. Page or object caching can reduce repetitive read operations and, consequently, database queries; however, it does not turn a write-intensive application into a low-conflict SQLite installation. Conversely, SQLite does not replace a caching strategy. For existing websites, continuing to use MySQL or MariaDB in conjunction with appropriate caching may therefore be the lower-risk approach without changing the database platform.

Systematically Evaluating Scenarios Using SQLite

Whether SQLite is suitable for WordPress depends not on the number of visitors, but on the interplay of write operations, server configuration, and extensions. SQLite can handle concurrent read operations, but it cannot execute write operations on the same database file concurrently at will. Therefore, a single website with a high volume of page views is not automatically unsuitable, whereas orders or bookings triggered simultaneously can be problematic.

The table is a preliminary selection, not a definitive list. Especially for a small business website, a CRM form, a members-only area, or an external automation service can turn a site with infrequent posting into one with a high writing load. Conversely, a blog with many readers remains a plausible candidate if comments, forms, and administrative changes are manageable. The plugin itself points out that suitability depends on traffic and writing load.

Multisite is described in the project documentation for the development branch as a configurable scenario; the repository also contains dedicated tests for it. However, this does not imply general production approval for large networks with many editors, sites, or integrations. Therefore, treat a network as a separate compatibility case and verify the actual administration, update, and content workflows in use.

The mandatory practical step is to test the specific stack in an isolated environment. This includes the active theme, all production plugins, custom MU plugins, importers, forms, REST endpoints, as well as backup and monitoring tools. It is not just a matter of whether pages load: Every extension with its own SQL assumptions or frequent changes must reliably pass through the SQLite layer.

Setup and Secure Path Configuration

This setup is suitable for a new test installation or a carefully planned SQLite installation, but not as a quick fix for an existing production environment. Before activation, PHP must have the extension pdo_sqlite Provide PDO support; the plugin also requires SQLite version 3.37.0 or later. PHP must have write permissions for the selected database directory. The setup dialog checks these requirements and also detects any existing, conflicting database drop-ins.

The specified minimum SQLite version is a technical requirement for the plugin, but not a blanket guarantee for every production use case. Since plugin version 3.0, Write-Ahead Logging Enabled by default. Administrators should therefore check which SQLite library the PHP runtime is actually loading and include plugin, PHP, and SQLite updates in their maintenance and compatibility checks.

Pay special attention to wp-content/db.php. This file is the central WordPress drop-in for the database layer; two solutions cannot use it at the same time. If a drop-in already exists there—for example, for a different database connection or a caching solution—you must determine before installation which component it provides and whether it can be cleanly removed.

The stable version 3.1.0 uses randomly named subdirectories by default under wp-content/database/. The detected storage location is stored in db-path.php recorded and via DB_PATH provided. Backup and migration tools must therefore not assume any historical filenames or a default path that may have been used. The previous constants DB_DIR and DB_FILE are marked as deprecated in 3.1; DB_PATH takes precedence.

For a planned new installation, the project recommends an absolute path outside the publicly accessible web directory. The target directory must be writable by the PHP process. The following setting should be placed in wp-config.php and is an example configuration, not instructions for retroactively modifying a live website.

// Dateikonfiguration wp-config.php:
// Beispielpfad außerhalb des öffentlich erreichbaren Webverzeichnisses.
define( 'DB_PATH', '/private/wordpress/database.sqlite' );

Warning: A newly set DB_PATH It does not move an existing database file. Instead, it selects a different storage location. If this value is changed without proper preparation, WordPress may end up using a different database or an empty one. Be sure to plan the path, access permissions, backup, and a restoration test together before deploying to production.

The random directory structure in version 3.1 merely reduces the predictability of the default path. It does not replace file system permissions or a storage location that is reliably protected against public exposure. The safest option is the recommended path outside the web root; if a different storage location is chosen, web server access to it must be just as reliably prevented.

No database change upon activation

For an existing WordPress website using MySQL or MariaDB, enabling SQLite Database Integration does not involve a migration. The plugin creates a separate, initially empty SQLite database. Posts, users, settings, media files, and plugin data from the previous database are not automatically transferred. If the integration is later deactivated, WordPress will reconnect to the previous database; changes made in SQLite will not be transferred back.

This separation is useful for testing, but essential for production migrations. Anyone who actually wants to migrate content to a different database platform needs their own, well-documented migration plan, including data transfer, verification of character sets and options, and a fallback strategy. Simply switching the drop-in cannot replace this process.

The term separate data sets This should be taken literally: During SQLite operation, the two databases may contain different content. A test post in SQLite does not suddenly appear in MySQL or MariaDB after SQLite is disabled. Similarly, a new MySQL post remains invisible as long as WordPress uses the SQLite file as its active data source.

The Repository wp-sqlite-db It describes itself as a standalone project with a single SQLite drop-in and refers to the original SQLite integration. It should therefore not be confused with the current WordPress repository. Files, configuration settings, and instructions from this project should not be applied to the current SQLite Database Integration; the documentation for the specific project being used is authoritative in each case.

For existing websites, the lower-risk decision is often to stick with MySQL or MariaDB and investigate bottlenecks separately. Page or object caching can reduce database queries, but it does not replace data migration and does not resolve compatibility issues with SQLite integration. This overview helps classify typical WordPress queries and caching approaches: WordPress Performance and Caching Optimization.

Protecting and Consistently Backing Up an SQLite Database

With SQLite, the WordPress database is stored in a single file on the server. It may contain content, user accounts, options, and configuration data, among other things, and must therefore be protected just like a database server. A randomly named default subdirectory that uses version 3.1 merely makes it more difficult to guess a path; it is no substitute for properly configured file permissions or web server access restrictions.

The project recommends that, DB_PATH Specify it as an absolute path outside the web root. PHP requires write permissions there, while the web server must not serve the database file directly. This separation reduces the risk that a misconfiguration within the publicly accessible directory could make the file accessible. Deployment, permissions management, and backups must explicitly account for the chosen storage location.

For backups, starting with the 3.1 release line, it is crucial not to hard-code any historical filenames or default paths. The plugin can determine the actual path via DB_PATH make it available at runtime; backup, migration, and restoration tools must therefore determine it after WordPress has loaded. Before deploying, you should perform the restoration in a separate environment and document the required path, configuration, and steps involved.

Starting with plugin version 3.0, the integration uses WAL mode by default. In addition to the main database, this allows for the use of auxiliary files with the extensions -wal and -shm may occur. Therefore, be sure to verify that the backup tool you are using supports WAL operation for the running SQLite database and takes these components into account. Without such tool support, simply copying the main file will not result in a consistent backup.

The minimum version of SQLite (3.37.0) specified by the plugin represents the technical lower limit for integration. For operation, you should also monitor which version of SQLite PHP is actually using and incorporate security and bug fixes for the PHP and SQLite packages in use into your regular update process. However, without a matching source in the existing source repository, it is not possible to derive a reliable recommendation for individual higher SQLite versions or specific backports.

Export and backup tools should not be used simply because they are familiar from MySQL or MariaDB installations. For each specific tool, check whether it supports the SQLite database in the current DB_PATH and supported in the configured journal mode. Then perform a restore in the designated hosting environment and document whether the database path, required database components, and WordPress configuration are fully merged.

Identifying Conflicts and Examining Them in a Targeted Manner

The migration should initially be performed on a staging or test environment, not as part of the first production rollout. Before installation, record any existing files under wp-content/db.php as well as plugins, MU plugins, and custom extensions that make direct use of MySQL. A second database drop-in cannot run in parallel; therefore, the integration setup process checks for such conflicts.

Next, test specific workflows rather than just the home page: login and administration, content creation, search, forms, scheduled tasks, import and export, as well as backup and restore. Repeat the tests after plugin and WordPress updates. The integration layer processes MySQL syntax for SQLite, but the support described in the project documentation does not replace testing your own queries or less common functions of a plugin.

Common setup mistakes include a lack of pdo_sqlite respectively pdo or insufficient write permissions for the database directory. Equally problematic is the assumption that activation will carry over content from an existing MySQL or MariaDB installation: It creates a separate SQLite database; it does not automatically perform a data migration. Even a new DB_PATH does not move an existing file, but rather points to a different location.

If wait times occur under load, first investigate which actions are writing data simultaneously: for example, orders, form processing, REST requests, or background tasks. SQLite allows multiple readers but serializes write operations per database file; multiple web servers also place greater demands on the database architecture. This is not the same as the locking mechanisms in MySQL InnoDB. For troubleshooting conventional WordPress databases, see the article on Concurrent database accesses and locks.

Choosing the Right Database Strategy

SQLite is a viable option for WordPress if the website runs on a single system, is primarily read-only, and concurrent changes are limited and well-defined. Local development, demos, or small editorial websites are better suited for this than applications with high transaction volumes. A prerequisite remains the proven compatibility of the actual theme, plugins, importers, and all custom database accesses used.

In the case of distributed deployments, multiple web servers, or a concentrated volume of write operations, MySQL or MariaDB the more appropriate database strategy. This applies in particular to online stores that handle orders, reservation and ticketing systems, community features, and automated interfaces with a high volume of write requests. The decisive factor is not a general visitor count, but whether independent processes need to modify the same database simultaneously. For direct, simultaneous database access by multiple hosts over a network, SQLite generally recommends a client-server system.

For an existing website, switching platforms does not automatically mean a performance project. Object- or page-level caching can reduce database queries and PHP processing without replacing MySQL or MariaDB. Caching and SQLite thus serve different purposes: the former reduces repetitive processing, while the latter changes the database’s storage and operational model. The official WordPress requirements continue to list MariaDB or MySQL as standard database prerequisites.

Before approval, a go/no-go review should cover at least the following points:

• Architecture: Can WordPress run continuously on a single server without requiring multiple hosts to open the same SQLite file directly via a network file system?
• Write Patterns: Are parallel orders, bookings, forms, REST, or AJAX write operations limited and tested in a separate environment?
• Compatibility: Do themes, plugins, MU plugins, and custom SQL queries work in the test instance?
• Drop-ins: Is wp-content/db.php free of conflicts with database or caching solutions?
• Migration: Is it clearly documented that the activation does not import any data from MySQL or MariaDB?
• Runtime: Does the SQLite library loaded by PHP meet the minimum plugin version requirement, and are PHP, SQLite, and plugin updates included in the maintenance process?
• Backup: Does the backup determine the current DB_PATH, does it support the journaling mode in use, and has a restore been performed and documented in a separate environment?
• Operations: Are updates to the plugin and WordPress supported by a repeatable testing process?