Running WordPress on SQLite: Ditching MySQL for High-Performance Micro-Sites

For nearly two decades, WordPress architecture has operated under a single, immovable assumption: it requires a MySQL or MariaDB relational database. This dependency dictates how we provision servers, manage hosting resources, and deploy applications. However, the official SQLite database integration being advanced by the WordPress Performance Team fundamentally challenges this requirement, allowing developers to port the entire CMS into a flat-file database system.

Deploying WordPress on SQLite transforms the application into a highly portable, self-contained unit. This approach is not intended to replace multi-node, high-traffic enterprise architectures, but it offers a radically efficient alternative for lightweight digital assets.

Why Ditch MySQL for SQLite?

Standard relational database management systems (RDBMS) like MySQL run as separate background services that require their own memory allocation, connection pooling, and socket configurations. For high-traffic, highly concurrent applications, this architecture is necessary. For micro-sites, landing pages, personal portfolios, or headless API endpoints, it introduces unnecessary overhead.

SQLite eliminates the client-server database model entirely. It is a C-language library that implements a small, fast, self-contained, high-reliability SQL database engine that reads directly from standard disk files.

Core advantages of a flat-file database approach:

• Zero Connection Latency: Database queries do not have to travel through network sockets or local TCP/IP connections; the PHP application reads the data directly from the disk.
• Reduced Server Overhead: By eliminating the MySQL daemon, you free up critical RAM and CPU cycles, which is highly advantageous on constrained shared hosting or basic cloud instances.
• Simplified Architecture: The entire application stack is reduced to just the PHP processor and the web server, drastically reducing potential points of failure.

The Technical Setup: Implementing the Drop-In

Converting WordPress to run on SQLite must occur before you run the famous 5-minute install. You cannot seamlessly switch an existing MySQL-based WordPress site to SQLite without a dedicated data migration tool; this workflow is designed for fresh installations.

1. Download WordPress Core: Extract a fresh installation of WordPress into your server directory as usual.
2. Acquire the Integration: Download the official SQLite Database Integration plugin from the WordPress repository.
3. Deploy the Drop-In: You do not activate this like a standard plugin. Instead, copy the db.php file from the downloaded plugin folder and place it directly into your wp-content/ directory.
4. WordPress natively looks for wp-content/db.php. If this drop-in file is present, the CMS automatically hands over database routing to it instead of using standard MySQL drivers.

Configuring wp-config.php

With the drop-in file in place, you must configure WordPress to establish where the SQLite database file will live.

Open wp-config.php and remove standard MySQL variables (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST). Replace them with the specific constants required by the SQLite drop-in to route the storage engine:

PHP

// Define the absolute path to the directory where the database file will be stored define( 'DB_DIR', __DIR__ . '/wp-content/database' ); // Define the name of the SQLite file define( 'DB_FILE', 'site-database.sqlite' );

When you navigate to your domain in the browser, the SQLite drop-in will detect the absence of the database, generate the site-database.sqlite file in the specified directory, and initialize the standard WordPress installation screen.

Security & Storage Routing on Shared Hosting

The most critical vulnerability of a file-based database is public exposure. Because the database is simply a file on the server, a malicious actor could theoretically download your entire database—including hashed passwords and user data—by navigating to [https://yourdomain.com/wp-content/database/site-database.sqlite](https://yourdomain.com/wp-content/database/site-database.sqlite).

If you are deploying this on traditional cPanel or DirectAdmin environments where you cannot easily route the database file above the public web root (public_html), you must secure the file using web server directives.

For Apache environments, create an .htaccess file inside your designated database directory (e.g., /wp-content/database/.htaccess) and apply the following rule:

Apache

# Deny public access to all SQLite files <FilesMatch "\.(sqlite|db)$">    Order allow,deny    Deny from all </FilesMatch>

Alternatively, if your server environment permits it, the most secure configuration is defining the DB_DIR path entirely outside the public-facing directory tree:

PHP

// Storing the database securely above public_html define( 'DB_DIR', '/home/username/application_data/database' );

The Developer Experience: True Portability

The ultimate payoff of the SQLite architecture is the developer experience it unlocks regarding backups, deployments, and cloning.

In a standard workflow, migrating a WordPress site requires archiving the files, running an SQL dump, transferring both components, importing the SQL file into a newly provisioned MySQL database, and updating connection strings.

With SQLite, the database is just another file in your directory structure. To back up the site, you simply zip the root folder. To migrate the site to a new server, you upload the zipped folder, extract it, and ensure the PHP processor is running. The environment is instantly live without provisioning databases, creating MySQL users, or configuring privileges. This file-based portability allows WordPress to be handled with the same agility as a modern, static frontend build.