Ari Stathopoulos 6:09 am on September 12, 2022
Tags: database ( 5 ), install ( 4 ), performance ( 308 ), sustainability ( 3 )

Let’s make WordPress officially support SQLite

WordPress can be (and is) used for any kind of site, regardless of size or complexity. Some common use-cases include:

Single-page landing sites
Simple company sites with just a few pages. These sites are usually rarely updated and are essentially static sites with an administration aspect.
Simple, single-user blogs
Complex news sites
e-Commerce sites
Full-fledged CMS solutions

Part of the success of WordPress is because it is extendable, hookable, and can be used and tweaked to accomplish almost any task on the web.

However, one aspect of WordPress has never changed, regardless of the increase in WP’s use cases and popularity: The database. WordPress requires MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/./MariaDB to be installed on a site. MySQL is arguably only optimal for some of the scenarios: The “mid-tier” range of site types.

Large sites usually implement custom database stacks depending on their specific needs, so are beyond the scope of this proposal.

On the lower end of the spectrum, there are small and simple sites. These are numerous and consist of all the blogs, company pages, and sites that don’t have thousands of users or thousands of posts, etc. These websites don’t always need the complexities of a MySQL/MariaDB database. The requirement of a dedicated MySQL server increases their hosting cost and the complexity of installation. On lower-end servers, it also decreases performance since the same “box” needs to cater to both a PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher and a MySQL/MariaDB server.

The ideal scenario

Ideally, WordPress would allow us to choose the type of database during installation. That could be done using an installation guide, or a simple constant in wp-config.php. To accomplish that, WordPress would need to have a database-abstraction layer. This is not an innovative or radical idea in the CMS space; Drupal has had a solid database-abstraction layer for more than a decade. Laravel, Symfony, and others also include ORMs that allow using multiple database types.

Building a database abstraction layer for WordPress would be a colossal task – though it might be one that, at some point in the future, we may have to undertake to ensure the project’s continued evolution and longevity.

A middle ground

As a middle ground, we could implement a solution for the bottom tier: small to medium sites and blogs. These sites don’t necessarily need a full-fledged MySQL database.

SQLite seems to be the perfect fit:

It is the most widely used database worldwide
It is cross-platform and can run on any device
It is included by default on all PHP installations (unless explicitly disabled)
WordPress’s minimum requirements would be a simple PHP server, without the need for a separate database server.
SQLite support enables lower hosting costs, decreases energy consumption, and lowers performance costs on lower-end servers.

Implementing SQLite in WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.

Using SQLite in WordPress is, at this point, simple; There are implementations out there that have been around and evolving for more than 8 years. They have been thoroughly tested and proved to work seamlessly. These implementations are drop-in wp-content/db.php files that users can add to their installation; they are not hard to use.

However, most people are not aware of them. They are not aware that they have the option to buy cheaper hosting sans-mysql and then install WordPress using an SQLite database. Nor should they have to know about it… After all, they just want a simple company site or a blogblog (versus network, site).

WordPress could officially support SQLite by including one of the existing SQLite implementations in Core. We would need to ensure that it is properly tested and supported, and additionally, raise awareness and expose the option to users.

Why should this be in Core and not a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party?

Picking a database type is something that should happen when a site is first installed. It is not something that should be done after the fact because that would require migrating data from one database to another, which can often be complex.

WordPress includes the MySQL implementation in Core, so if we support SQLite then that implementation should live alongside it.

Data migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. can (and should) be in a plugin to facilitate migrations for existing sites should they wish to do that, but the database engine itself belongs in Core.

That will ensure that the implementation is properly supported, properly tested, and WordPress will be able to benefit, as detailed in the following section.

What would the benefits of SQLite be?

Officially supporting SQLite in WordPress could have many benefits. Some notable ones would include:

Increased performance on lower-end servers and environments.
Potential for WordPress growth in markets where we did not have access due to the system’s requirements.
Potential for growth in the hosting market using installation “scenarios”.
Reduced energy consumption – increased sustainability for the WordPress project.
Further WordPress’s mission to “democratize publishing” for everyone.
Easier to contribute to WordPress – download the files and run the built-in PHP server without any other setup required.
Easier to use automated tests suite.
Sites can be “portable” and self-contained.

Next steps

The next steps would need to be discussed in the comments section of this proposal. If there is consensus to implement SQLite in WordPress Core, an outline of the next steps would look something like this:

Create the necessary TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets

Decide how the database type would be defined. The most simple scenario would be a DATABASE_TYPE constant in wp-config.php, allowing users to choose if their new site would use a MySQL or SQLite database, but there can be other solutions that come up during a later discussion.
Port an SQLite implementation to WordPress Core, applying the necessary changes like coding standards, in-code documentation, migrate tests, etc.
Test WordPress Core functionality with SQLite
Outreach to plugin developers for testing.

The subject of database abstractions and using SQLite was discussed at length during WCEU 2022, in an unofficial capacity, in the hallways. This post is a distilled culmination of these conversations to bring the discussion to the broader community for serious consideration.

Props @zieladam, @mamaduka, @jonoaldersonwp, @tweetythierry, @SergeyBiryukov, @joostdevalk, @dingo_d, @desmith, @crixu, @williampatton, @costdev, @adamsilverstein, @JavierCasares, @robinwpdeveloper, @aaemnnosttv, @jessibelle for reviewing and contributing to this proposal.

#database, #install, #performance, #sustainability

Jon Brown 6:42 am on September 12, 2022

I love the idea. The outlined benefits sound great, but what are the draw backs?

Hence I have a couple questions. What are the limitations of running WP on SQLite? Why not use it for all sites? Will there be a conversion tool built into WordPress to move a between the two DB options? How much hosting out there doesn’t actually support/include MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. by default today?

Seems those “small” sites might easily benefit from being static sites, would it make sense to look into static flat file sites generators as part of this?
- Ari Stathopoulos 7:19 am on September 12, 2022
  
  What are the limitations of running WP on SQLite? Why not use it for all sites?
  
  One of the drawbacks would be that SQLite wouldn’t perform as well in sites that have multiple authors for example. If multiple authors are editing posts on a site and updating them at the same time, then their save requests would run one after the other instead of simultaneously – so there would be a small delay (probably milliseconds, but still a delay).
  SQLite is a great tool, but it’s not a silver bullet – just like MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/.. MySQL is and should continue to be the default because if you have aspirations to be the next big thing, then MySQL can scale better. If on the other hand you just want a blogblog (versus network, site), a company site with your about page and a contact form to have an online presence, or any type of small site (which is arguably the majority of sites on WordPress) then SQLite is all you’ll ever need and it will perform a lot better.
  
  Will there be a conversion tool built into WordPress to move a between the two DB options?
  
  No. If you want to migrate from MySQL database A to B (both MySQL databases), WordPress doesn’t include tools to migrate that data. SQLite is no different… Data migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. doesn’t belong in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and should be in a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. It’s very possible to migrate data between databases, and doing it in a plugin (or WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/) is not a hard task. But it’s not a task that should be part of Core…
  
  How much hosting out there doesn’t actually support/include MySQL by default today?
  
  It’s not so much a question of support… it’s more a question of fine-tuning.
  If all I can afford is a low-end shared host for my blog, then that server is currently splitting its performance between MySQL & PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher. Most crashes I’ve witnessed in cheap shared hosts are database-related, and I’m sure a lot of people have similar experiences.
  If, on the other hand, my WordPress site is using SQLite, then the server can be better configured. All its resources get dedicated to PHP since SQLite is included in there. The host can provide better performance for the same box, by fine-tuning it for PHP only. By removing MySQL from the equation, the same site on the same server can perform better.
  
  Seems those “small” sites might easily benefit from being static sites, would it make sense to look into static flat file sites generators as part of this?
  
  That’s probably where aggressive caching comes in; there are a few plugins out there that do just that.
  - Fernando Jorge Mota (a11n) 5:24 pm on September 13, 2022
    
    One of the drawbacks would be that SQLite wouldn’t perform as well in sites that have multiple authors for example. If multiple authors are editing posts on a site and updating them at the same time, then their save requests would run one after the other instead of simultaneously – so there would be a small delay (probably milliseconds, but still a delay).
    SQLite is a great tool, but it’s not a silver bullet – just like MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/.. MySQL is and should continue to be the default because if you have aspirations to be the next big thing, then MySQL can scale better.
    
    I just want to add that, while it’s true that MySQL will definitely scale better for websites with many authors receiving thousands of visits/comments (mainly because you can have a replicated database setup with many web servers connecting to that setup), SQLite is quite scalable too.
    
    For instance, Expensify uses SQLite as a main database, and there are some efforts by the SQLite team to allow SQLite to scale better for writing, as well as tools for scaling SQLite for reading, too. We also have some third-party initiatives to allow SQLite to work as distributed database too, but let’s not talk about those. 🙂
    
    Anyway, just wanted to share a few things that might not be as well known to anyone that doesn’t know a lot about the SQLite ecosystem. By no means I think SQLite will ever replace MySQL, even with all those advances, but either way, I think that native SQLite support on WordPress would be something AMAZING to have and would open a lot of new opportunities for WordPress (like the idea of running WordPress on the browser, for instance).
ste18k 7:42 am on September 12, 2022

I really like the idea
I just see a side effect: some people will tend to buy the cheapest shared hosting offer (the one with SQLite) and then will complain because their site with WooCommerce and other tens of plugins will not work 🙂 but it will be up to us (hosting providers) to indicate which is the best product for each custormer…
- Ari Stathopoulos 8:14 am on September 12, 2022
  
  The people that will do that are probably the ones that already do it with MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. so I don’t think that anything will really change there… The ones with unreasonable expectations will always want the best hosting for free regardless of whether it’s using MySQL or SQLite.
  
  However, it would be relatively easy for a host to add a drop-in file in wp-content/mu-plugins, check if the site is using SQLite, and if it is then add some tweaks to the site’s dashboard. For example check if the database size is larger than 100MB (random number), and if it is then add a notice to recommend switching to MySQL. Or in the plugins screen add a notice next to their e-Commerce pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party if they have more than 100 products and you suspect that they are about to outgrow their plan.
  Hosts could even implement a plan depending on the number of posts a site has. Fewer than 1000 posts? Keep it on SQLite. Cross that threshold and the host automatically runs the upgrade routine to MySQL (with the user’s permission). 1000 posts by the way is not too little… It’s 1 blogblog (versus network, site) post per week for 20 years! Not many sites out there with that many posts.
  
  There are lots of things that hosts can do, and the above are just some random ideas – some good and some bad.
  As mentioned in another comment above, SQLite is not a silver bullet. It’s the optimal solution for a big chunk of the WordPress ecosystem but not for everyone – just like MySQL.
  Yes, it will take some work on the host’s part and it will take some time & research. But they will have the option to grow, offer new services and do some good.
  
  I also want to highlight a danger here, relating to the hosts ecosystem: Hosts should act responsibly. Having a cheaper plan without MySQL is a viable option, provided that it’s done reasonably. It’s not like servers should be half as powerful!! If we go that route then it will be extremely bad for everyone. The whole point is to improve performance, not cripple the web. An SQLite plan can have for example 10% lower specs – and that would allow it to run faster that it would if it was at 100% and had MySQL.
  Hosts will need to do a lot of experimentation to find a good and reasonable balance. But there is opportunity to grow, offer better services and scale more – provided that it’s done responsibly.
Samuel Wood (Otto) 8:13 am on September 12, 2022

… and “search” takes a massive dive.

I’m not against the idea, mind you, but list the cons as well.
- Ari Stathopoulos 8:22 am on September 12, 2022
  
  … and “search” takes a massive dive.
  
  Very true! I had not considered search. On the other hand though, on small sites with a relatively small number of posts (like a normal blogblog (versus network, site)), I don’t think that will be such a big issue… The search query will be slower due to the nature of SQLite, but still reasonably fast due to the small number of posts to query.
  If a site has 10k posts, then things obviously change, but such a site is rather huge and not your average blog or simple site
Marius L. J. 9:05 am on September 12, 2022

I’ve got another potential drawback that has not been mentioned here; file locking.

SQLite is a flat-file storage system, this means that multiple processes can read from it at once, but only one can write at any given time, and while a process is writing to the database, no other process may write or read from it.

This means that someone using a contact form pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party may inadvertently now temporarily lock down a site while an email is sent as the plugin stores the message and the sent-status to some custom postmeta (very edgy example, I know).

Another example would be WP_Cron, a long-running task of some kind may then lock down the entire site from both visitors and admins (for periods of time that are non-trackable).

This all boils down to one aspect in my mind though: interoperability.
It feels backwards to require a host to add filters to popular plugins because they may not work in this scenario (or for coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. them out based on arbitrary rules), or core needing to remove WP_Cron support (and thus also automated updates!) because WP_Cron might lock a visitor or an adminadmin (and super admin) out of the site for intermittent periods of time.

—

Very happy to be told this is no longer the case though, as I like the idea, and I think there are various benefits to it as you say (your site is now just a microservice that can run `php -S` for example), or just the thought of not needing anything other that that built in webserver for testing!
- Ari Stathopoulos 9:26 am on September 12, 2022
  
  Yes, that’s what I was referring to in my comment above too.
  However, these queries take milliseconds and we can easily add a “queue” to avoid any issues. If I’m not mistaken, the existing SQLite implementations already take that into account – though we should run lots of tests and ensure there are no issues.
  
  EDIT: As mentioned in other comments, Since SQLite 3+, locking is a smaller issue and in SQLite 3.7+ there is a WAL mechanism to allow for concurrency
- thatnerdyguy 10:44 am on September 12, 2022
  
  Check out https://www.sqlite.org/wal.html
  - Ari Stathopoulos 11:09 am on September 12, 2022
    
    Thanks for the link!
Svetoslav Marinov 9:46 am on September 12, 2022

Cool. Idea. It was about time to do that.
maximeschoeni 10:02 am on September 12, 2022

Long time ago there was a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party in the wp repo that actually brought support to sqlite. As far as I remember it was super easy to install and just did the job. I dunno why the plugin was removed from repo, probably a licence issue.
- Ari Stathopoulos 10:14 am on September 12, 2022
  
  All SQLite implementations I’ve seen are basically forks and descendants of that old pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party… So all that work did not go to waste, it just kept evolving and there are a few forks of it on GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/.
  The most widely used one is https://github.com/aaemnnosttv/wp-sqlite-db and a proof-of-concept PR for WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. that I’ve been working on for testing purposes can be seen on https://github.com/WordPress/wordpress-develop/pull/3220 (basically just splitting the db.php file to separate classes, applying coding standards, adding things to the Health-Check screen etc).
Terence Eden 10:11 am on September 12, 2022

As a reminder, SQLite has a religious code of conduct which puts off people from contributing to it.

I certainly wouldn’t be comfortable integrating this into any of my sites or products.
- Ari Stathopoulos 10:21 am on September 12, 2022
  
  I agree, that code of conduct reads more like a Bible/Quran, but can you say that contributing to SQLite is harder than contributing to Oracle’s MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/.? 😅
  WordPress has some people contributing to PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher, but contributing to database engines is a completely different beast…
  WordPress has never contributed to MySQL or MariaDB. Contributing to SQLite should not be a consideration, the project is open-source and its popularity speaks volumes regarding what it can do and where it can be used.
  - Terence Eden 11:27 am on September 12, 2022
    
    It is popular at the moment. But the fact that all of the developers subscribe to one specific religious doctrine may be a bottleneck in future. Having a monoculture like that doesn’t seem – to me – to be a good way to maintain longevity.
    
    Why tie a global an inclusive project like WordPress to something so insular?
    - Ari Stathopoulos 1:03 pm on September 12, 2022
      
      It already is tied… Your browser uses SQLite internally. Your phone/tabled and all other devices use SQLite. Every single app you use, uses SQLite. Chances are the OS does too – though not 100% on that.
      
      The WP data itself may not be stored in an SQLite database, but the tech we use to write, access and distribute that data, for the most part is built around SQLite.
      
      I don’t disagree with you at all! But I don’t think we should make technological decisions based on whether we agree or not with a person’s or group’s religious beliefs. We should not dismiss a tech just because we don’t subscribe to the creator’s religious beliefs.
      
      The technology is good, it is used everywhere, and it’s not going away – in fact, it’s constantly growing.
      - Jon Brown 5:47 pm on September 12, 2022
        
        Ugh that’s gross and makes it a hard no from me.
        
        I don’t have issue with the creators _belifs_ it is an issue with enshrining those beliefs in the code of conduct.
        
        I couldn’t in good conscience use this because I’d be violating the Code of Conduct. I do see it as different if/when it’s incorporated into a piece of software I use (ie chrome) vs a piece of software I actively contribute to (ie WP).
        
        So, nope… I’m out.
        
        Ari Stathopoulos 5:25 am on September 13, 2022
        
        Their code of conduct refers to people who want to contribute to SQLite and be a part of their project. It has no effect and does not apply to projects that want to use SQLite.
        It’s just like WordPress… Anyone can use WP to build their site, but if you want to contribute, you need to follow our code of conduct.
    - Andrew Wilder 12:15 am on September 13, 2022
      
      On the other hand, “The intent of the developers is to support SQLite through the year 2050.”
      https://www.sqlite.org/lts.html
- n3storm 10:25 am on September 12, 2022
  
  I don’t think the name of Christ in the code of conduct is literal (I am atheist myself)
  The key is the wording “follow the spirit of the rule” and also “In other words, the developers are saying: “We will treat you this way regardless of how you treat us.” ”
  So “Christ” in this context is “the other” person you are developing with.
  Is it unfortunate to choose this exact wording? I agree.
  Should this wording blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. any collaboration? I don’t think so.
  - Rob Howard 12:36 am on September 13, 2022
    
    The code of ethics links to an interview with the SQLite founder in which he states that it is not a joke or tongue in cheek, and that he really thinks codes of conduct that protect against non-discrimination are too woke. It struck me as a joke at first too, but it doesn’t seem to be. I agree that tech choice shouldn’t be unduly influenced by private beliefs of a developer, but this is very clearly, intentionally, publicly tied to the software, so the “private beliefs” thing doesn’t seem to apply. I don’t think it’s necessarily grounds for not doing this, but if it becomes official I think we should at least have some sort of statement clarifying that WP believes non-discrimination policies are a good idea.
mobilio 10:53 am on September 12, 2022

That’s fantastic news and i’ve waiting years for that announce.

But web servers today was different than servers 15 years ago.

One of easiest edge scenario is with PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher-FPM. One of processes can open DB for reading and few millisecond later other can try to open it again for writing. This can halt all other processes working with DB.

If we have one user that edit posts using WP GUI then this will be OK. But situation become worse if some pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is trying to write in DB when visitors read posts (like page counters). Also this may lead to loss of orders in case of Ecommerce site.

Anyway – i’m optimistic for this!
- n3storm 11:00 am on September 12, 2022
  
  With WHAL enabled concurrent writting should not be an issue:
  https://www.sqlite.org/wal.html
- Ari Stathopoulos 11:08 am on September 12, 2022
  
  Concurrent read/writes are no longer an issue since SQLite 3.7 as mentioned above (WAL). The good news is that SQLite 3.7 is the de-facto in PHP7+ if I’m not mistaken, and as mentioned my previous comment, these queries take milliseconds and there are ways around the locking thing (already implemented in the SQLite implementations for WP)
  - mobilio 10:42 pm on September 12, 2022
    
    Sure, but it’s also depends on scenarios.
    
    I’ve using SQLite on few projects locally. And to get best performance i use pragma synrchonous=off and pragma journal_mode=memory.
    
    Because for mine case i download few GB from APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. services and i need to store ASAP into database. There is chance of DB corruption, but i make backups each week.
    
    So – when journal is in memory:
    https://www.sqlite.org/pragma.html#pragma_journal_mode
    it’s make less disk activity and on overload computers this can be easy seen.
CodeBard 12:55 pm on September 12, 2022

This feels like it could be better done through a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. The very cons that you yourself list, that range from not working well in sites with multiple authors to plugin compatibility to ‘web hosts needing to act responsibly’, make it a no go for being introduced into the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

People don’t care about any of the stuff that we obsess ourselves about in software development. Less, in Open SourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL.. They have businesses to run, and lives to live. Nobody will appreciate the disruption of their workflow, less their businesses, so that some OSS project could push into WP ecosystem like this.
- Ari Stathopoulos 1:15 pm on September 12, 2022
  
  not working well in sites with multiple authors
  
  Apparently that was an issue in older versions of SQLite but not an issue any longer as mentioned in other comments above.
  
  pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party compatibility
  
  I have not found a single plugin that has an issue. As long as plugins use $wpdb to access the database, everything works seamlessly – and I have not seen a plugin that accesses the db with hardcoded username/password credentials and direct queries bypassing WP. Last time I saw a nightmarish implementation like that was probably a decade ago.
  
  web hosts needing to act responsibly
  
  That’s also true now with MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/.. The fact that I’m bringing attention to it now, does not mean that this is specific to SQLite. If a host does a bad job, they’ll get bad results – no matter the DB-type used.
  
  People don’t care about any of the stuff that we obsess ourselves about in software development
  
  They do care about cost, performance, sustainability, all the things that affect them and their company. SQLite is a tool to achieve these things. It’s not better or worse, it’s just a different tool for different scenarios because the current tools we use are lacking in many areas.
  - CodeBard 1:53 pm on September 12, 2022
    
    I have not found a single pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party that has an issue. As long as plugins use $wpdb to access the database
    
    Are you saying that all the 60,000+ plugins in the database would support SQLite as a drop-in without any issues with queries from MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. 5.7?
    
    That’s also true now with MySQL.
    
    MySQL is already adopted by the industry, and everyone has best practices, and common standards for using it. No web host will go for the effort of making the same happen for SQLite or another database engine for that matter.
    
    They do care about cost, performance, sustainability, all the things that affect them and their company
    
    No, really, they don’t. Because the improvement, sustainability, ‘all’ the things that SQLite or any other database engine or, actually, any other software or stack provides, are invisible to the end users. A ~10% improvement in the load time of a WordPress page that takes ~1.5 seconds to load won’t even be noticeable by any user. Background queries that take ~0.5 vCPU every other cron run being improved 20%, reducing the total monthly CPU usage of a WP website from ~$3 worth of vCPU to ~$2.98 worth of CPU won’t be anything to notice for the users. Even for the web hosts – the continued engineering and support costs of having to support another database engine makes that saving negligible.
    
    Let’s face it: If any language, database engine, or stack made enough difference over what is already used in a given ecosystem, it would already be adopted. This is not valid for WP only, it’s valid for every use case.
    
    But the reality of actual user space is that users don’t care about the esoteric programmers’ trappings that we care about so much. Something that looks ‘cool and great’ to us is irrelevant to users. Some 15% improvement in certain queries in a database engine is cool and great for us, but the users don’t even care. Less, they would want to stop their daily lives and business to do anything to accommodate it.
    
    As I said, doing this through a plugin is much better. It wouldn’t disrupt anything. The SQLite project can maintain the plugin themselves if they want to. And if the plugin gets to a few million users, then that would be a legitimate use case for SQLite to be introduced to the WP ecosystem in WP coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
    - Ari Stathopoulos 2:51 pm on September 12, 2022
      
      I see great potential for growth in this proposal, you don’t. That’s fine… Different opinions doesn’t mean one is right and the other one is wrong, it’s just different perspectives on the same subject – both equally right from their own point of view.
David Anderson 1:50 pm on September 12, 2022

Interesting idea, but I’m wondering how much the items under “What would the benefits of SQLite be?” have been looked into. Are these benefits that might potentially exist, and someone should investigate them? Or they’re known to exist, and have (where relevant) been quantified? Isn’t that one of the first things that should be worked out before any of the rest (otherwise it’s just playing with toys for fun – which is great, but, not yet relevant to others).
Brian Layman 4:50 pm on September 12, 2022

This was a relatively easy to do with dropins a decade ago when the ezSQL code in wp-db.php was a very slightly modified version of the original ezSQL project.
https://justinvincent.com/ezsql

Back in 2006 I even had WordPress running off of the FireBird open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. DB engine (which I’d hoped would catch on as it was way more advanced than MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. back then). The engine is still around, but I’m sure my code won’t work.
https://firebirdsql.org/

We’ve kind of moved out of compatibility with ezsql as our code modified from the old v1.25 of ezsql and version 5 is backwards incompatible but current and supports PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 8.1. But maybe this is the way to go for a project like this.

EzSQL allows you to just choose which engine to run from a big long list: PHP-PDO, mySQL, Oracle8, InterBase/FireBird, PostgreSQL, SQLite (PHP), SQLite (C++), MS-SQL and others. So if we are going to put effort into bringing in other engines, why just choose one?

Create a modern wp-db.php or wp-content/db.php that works with the current ezSQL. Reap the benefit of all the work done in that project, modernize WordPress’s implementation, add do it in a way that allows plugins to easily choose between 7 additional engines instead just 1 more.
Andrew Wilder 5:58 pm on September 12, 2022

That religious code of conduct is definitely a dealbreaker for me. Language like “…love the Lord God…” (#1) and “Prefer nothing more than the love of Christ.” (#21) is exclusionary to anyone who does not believe in the same and is therefore antithetical to the wonderful inclusivity of WordPress.

Having said that, if this is going to move forward anyway:

Reading the comments and potential issues above, if this does move forward, perhaps the way to implement this in a way that makes sense to users would be to brand it simultaneously as “WordPress Lite.” So if a site is using SQLite, there could be features that are simply no longer available (such as multiple authors, or perhaps plugins that have certain database requirements can’t be installed).

Also, would transients cause performance issues?
- Ari Stathopoulos 5:29 am on September 13, 2022
  
  As mentioned in other comments, concurrency is no longer an issue with SQLite 3.7+ using WAL, so I don’t expect we’ll have any issues on that front.
  
  Also, would transients cause performance issues?
  
  Not from what I’ve seen in my tests and experiments in the past 10 months
  - Andrew Wilder 1:29 pm on September 13, 2022
    
    👍
Matt Mullenweg 6:07 pm on September 12, 2022

I like this! I talked a bit about SQLite on stage at the Q&A at WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. US in San Diego this weekend.

https://wordpress.tv/2022/09/12/a-chat-with-matt-mullenweg-wordcamp-us-2022-qa/
- Andrew Wilder 6:21 pm on September 12, 2022
  
  Hi Matt! Really enjoyed the Q&A on Saturday. 😁
  
  How will we reconcile the concerns about SQLite’s code of ethics, which uses language that, at least in part, strikes me as contrary to the inclusivity that is so cherished and celebrated in the WordPress community?
  
  This may be such a polarizing issue that I’d hate for months of work to go into incorporating SQLite only to have it be shut down later because of this conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved.… so it seems best to figure this out sooner rather than later (whatever that means).
  - Colin Stewart 11:15 pm on September 12, 2022
    
    I agree that we should figure this out sooner rather than later, and I’ll admit that I felt uncomfortable reading SQLite’s Code of Ethics.
    
    However, I also saw this in the Code of Ethics:
    “No one is required to follow The Rule, to know The Rule, or even to think that The Rule is a good idea. The Founder of SQLite believes that anyone who follows The Rule will live a happier and more productive life, but individuals are free to dispute or ignore that advice if they wish.”
    
    So while the founder of SQLite believes this and has chosen to wear their beliefs on their sleeve, it isn’t a “requirement” or anything, and therefore not exclusionary in nature. Does it belong in software projects? I, and many others, would say no, but it isn’t my software project nor one I contribute to. That said, SQLite is used widely (and by some I know don’t share its founder’s beliefs) so the Code of Ethics hasn’t been exclusionary for them. I’d also hazard a guess that most users of SQLite are completely unaware that it even has a Code of Ethics.
    
    The mention of beliefs is not exclusionary by itself, unless the beliefs specifically aim to exclude a certain group of people. So, do they? From my perspective, I didn’t see anything that aimed to exclude a group of people. You either agree with the contents or you don’t, and the founder doesn’t have an opinion on whether or not others agree.
    
    I’m happy to go with consensus on this once others voice their opinions, especially as this may require a statement of some kind should the issue become very controversial within the community.
    - Andrew Wilder 12:54 am on September 13, 2022
      
      I agree. I’ll admit I had a knee-jerk reaction to seeing the religious references — and my eyes went straight to that part of the page — so at first glance I missed that section, and assumed they were requirements for end users, not just their own contributors. So this puts my own concerns to rest.
      
      (I do also want to quibble with #54 though… No sense of humor?? Boo! 😆)
      - Colin Stewart 1:13 am on September 13, 2022
        
        lol 😆
  - Matt Mullenweg 10:24 pm on September 14, 2022
    
    I can almost guarantee you’re already using SQLite right now, as it’s built into iOSiOS The operating system used on iPhones and iPads., MacOS, and Android. Fun fact: All your iMessages on Mac are in a SQLite database you can connect to and query. (It looks like they’ve locked something down and sudo -s isn’t getting around it, but you used to be able to sqlite3 ~/Library/Messages/chat.db.)
    - Andrew Wilder 10:27 pm on September 14, 2022
      
      Neat! (Though I’m on a PC, so that would really be quite some trick! 😉)
      
      I’ve made my peace with their “Code of Ethics” — since it’s only required for SQLite contributors and they make it clear that nobody else needs to follow or agree with it.
- Ari Stathopoulos 6:11 am on September 13, 2022
  
  Thank you Matt, that’s perfect timing!
  
  For anyone coming to this post and reading the comments later, I’ll add some extra info here: You can find the part mentioning SQLite around 9:15 on that video, and I’m adding a transcript below for improved accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility):
  
  I’ve been thinking a lot about projects that really build for the long term. Think not just in years but in decades, and of course, Open-Source has some of the best of these.
  What I’ve been virtually enamored with recently, is actually SQLite.
  They try to think about their data formats, being accessible for decades to come. A really safe data storage format for rich data.
  Something a little more native in terms of supporting SQLite I think would pair very well with WordPress’s thoughts on longevity and permalinks and everything like that that we’re trying to support.
ryanmclaughlin1 6:27 pm on September 12, 2022

I am surprised no one is bringing up security here…

In your linked pull request draft it looks like the database is stored in the wp-content directory by default which is publicly accessible.

Granted – it is a hidden file which common server configs will prevent from being served to users, but we can’t count on this to be in place.
- Colin Stewart 10:57 pm on September 12, 2022
  
  In terms of permissions, I raised this with Ari during review and we discussed possible checks via Site Health and such. That, paired with plans to increase the visibility of severe Site Health issues, should help on the security end.
  
  FWIW, this isn’t much different to directory indexes being available. It’s a server configuration issue, but we can still warn site owners if their SQLite file is exposed.
  - Ryan 5:18 pm on September 13, 2022
    
    Site health checks would be a step in the right direction but I don’t think it is enough. Less tech-savvy users will just ignore the warnings.
    
    And I don’t think directory indexes are a fair comparison here…
    
    When directory indexes are available it allows an attacker to more easily find files that you wouldn’t want them to, sure. But disabling indexes doesn’t do anything to secure those files – they are still accessible to the public, just harder to find. The correct fix is not so much about server config as it is to get rid of those files.
    
    With the sqlite file we are talking about exposing the entire database to the public. Most importantly that includes private user data, but also things like api keys, etc.
    - Ari Stathopoulos 7:01 pm on September 13, 2022
      
      The current implementation is pretty simple, but there are definitely steps we can take to address any and all security issues.
      We can disallow indexing in that folder, add an index.htmlHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers./index.php file in the db folder, use the salts constants from wp-config to generate a hashed filename or folder name for the db, place it outside the httpHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. folder, add entries in .htaccess to disallow accessing that file and a bunch of other things too.
      This community has the people, the expertise and a combined brainpower able to address any security concerns that may come up during the implementation period.
      
      Also, it’s worth keeping in mind that there are many other CMSs out there that use SQLite as well, and have never had any security issues with it (Drupal comes to mind), so we know that there are solutions to these things.
      - Ryan 5:09 pm on September 15, 2022
        
        Yes – all sound like decent options. I just wanted to make sure to bring this issue up before development gets too far along.
        
        Personally I think the suggestion by @costdev of effectively locking down the site when an insecure sqlite configuration is detected would be best, but I am sure others will bring up some good options as well.
        
        And FWIW from a developer perspective I am very excited at the prospect of native support for sqlite. Best of luck moving forward with this proposal!
    - Colin Stewart 12:14 am on September 15, 2022
      
      Some possible solution are 1) server config (i.e. permissions on the file), 2) not having a file for the database, 3) making use of .htaccess, or 4) storing the database in a directory that isn’t publicly accessible.
      
      Since this proposal relies on a file for the database, that’s option 2 out. I’m not particularly in favour of a .htaccess solution since plugins and users regularly interact with this file (that’s option 3 out for me), and we don’t have control of which directories are public or not, except within the wordpress directory which can be different depending on the environment (that’s option 4 out for me).
      
      Of those options, that leaves option 1. So, what we could do, for example, rather than just a Site Health Check, is refuse to use a database file that has public visibility. A message – very similar to “Error establishing database connection”, except “Error detecting a secure SQLite database. Please verify that the permissions on your database are correct. See here” could be shown.
      
      Also, as Ari said, we can look at other implementations to see how we might implement similar in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
      - Ryan 5:12 pm on September 15, 2022
        
        Yes option 1 is pretty much where I landed as well, but as mentioned hopefully there are some other approaches to be found looking to the broader PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher ecosystem.
Stanislav Khromov 7:04 pm on September 12, 2022

This is a great idea, but the current way of heavily utilizing regular expressions to rewrite existing SQL queries to “massage” them into being SQLite compatible seems pretty brittle. It’s not impossible (can be done with a very strong unit testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. suite to test for correctness).

However I think the better option would be to abstract away the current usages of $wpdb->query() in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. code with dedicated DB functions that can be added to the `wpdb` class. So instead of calling `$wpdb->query(‘INSERT …’)` from `wp_insert_post()` we would call `$wpdb->insert_post($args)`. This would not only allow for a clean and testable implementation of the SQLite adapter but also to port WordPress to non-SQL databases. Since each function is well defined we could implement WordPress on top of any database. Think WordPress on CouchDB, Postgres, Firebase or even Redis. The sky would be the limit.

When I search in the WP codebase there are 174 uses of `->query()`. A large amont but not impossible to refactor for the huge gaines as outlined above.
- justlevine 8:13 pm on September 15, 2022
  
  +1
- shawfactor 3:19 pm on September 21, 2022
  
  Abstracting away $wpdb sounds great until you find that you need to do a customs query in your pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. Then suddenly your plugin does not work across all database types
Robert Anderson 11:31 pm on September 12, 2022

I think it’s a great idea. @zieladam has been experimenting with running WordPress using a WebAssembly build of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher and SQLite which has some pretty powerful applications. Officially supporting SQLite would assist with those efforts.
Rob Howard 1:15 am on September 13, 2022

As a developer, I understand the value here. However, I do not see how adding more complexity to the installation process would help a non-technical user. By definition, the “blogblog (versus network, site) and small site” audience that would theoretically benefit from this would have no idea the difference between the two database options. They’d simply be confused by more options with obtuse yet similar names.

Hosts could start offering “Mini WordPress” that only uses SQLite, but as others have mentioned it seems like it would be hard to explain the difference/drawbacks on a pricing page. Is there an untapped market of people who want one user, slow search and limited pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party availability?

I think the theory makes sense that this could reduce server load, but I think the use of SQLite might be an idea that’s mostly appealing to coders, while being framed as something that lots of laypeople would use.

Do we have data or examples to support the hypothesis that this would be adopted by real laypeople who aren’t coders and thus capable of using the existing methods already?
Thomas Patrick Levy 3:39 pm on September 13, 2022

Hey ari thanks for this write up and proposal, in general I think this is an interesting idea and providing more options and, maybe even more specifically building an ORM into WP sounds beneficial.

I have a few small websites that are rarely updated and collectively have fewer than 100 posts in them (single user sites). I host them on $5 / month digital Ocean droplets and they work absolutely fine. I know Lightsale has instances that might be closer to $3 / month.

How much money could sites like these actually save switching to SQLite?
- Ari Stathopoulos 6:34 am on September 14, 2022
  
  A single droplet should be able to handle all these sites at the same time… From your comment above I assume right now they are in individual droplets, so they could easily be combined and live under the same roof.
  
  Of course it depends on the traffic they receive and what kinds of plugins run on them, but I see no reason why a DO Droplet wouldn’t be able to handle them all if they have some basic caching
DjZoNe 7:52 am on September 14, 2022

I don’t want to be offensive, or anything, but I feel like that SQLite is just not the right way, I mean it feels like we’re developing backwards. Like what will be the next? CSV fallback?

Even Matt mentioned years ago that maybe in the future the default database will be MongoDB, to be honest I was more excited about the idea of supporting NoSQL than I’m for SQLite, I understand it’s way less work and development time. But it’s really a good way?
- Ari Stathopoulos 7:56 am on September 14, 2022
  
  Hello there @DjZoNe!
  
  Could you please explain why you feel this way?
  What’s wrong with SQLite? Why do you say it’s not the right way?
DjZoNe 8:04 am on September 14, 2022

SQLite is just a simplified SQL server, it’s more like that for that compatibility we have to give up on features that MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. has.

Which is fine, if there’s a greater good, for example Stanislav Khromov mentioned in a comment above, he summed up what I think about the right direction.
Xavi Ivars 11:12 pm on September 14, 2022

I really love the idea. I maintain some WordPress sites that I would probably never move to SQLite, but there are some others (including my own blogblog (versus network, site)) that I would love to run in SQLite. And I never thought about using a plug-in for it because without coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. commitment, the plug-in could break at any time.

And on top of actually using this in production, there’s something else the WordPress contributors would be benefit dramatically: developer experience. It’s a pain when developing in WordPress (a plug-in, a theme or even a library), to require a DB server to do something as easy as running unit tests. There are plenty of bash scripts that are copy pasted from githubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repo to github repo, `install-wp-tests.sh` that not only sets up the environment with phpunit and maybe downloading WordPress itself, but así require a connection to a mysqlMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. server with permissions to create databases. That’s just the opposite of the type of isolation you want when running tests!

Full, official support for sqlite would make it so much easier to build and run those tests…
justlevine 8:01 pm on September 15, 2022

Idk yall, this doesn’t seem to jive with the ‘decisions not options’ and the 80:20 philosophy.
Especially at a time when other non-gb projects are struggling with contributors, Matt is pushing again for canonical plugins, and (according to the other comments), there are already solutions for using it.

If anything I believe the ‘middle ground approach’ _is_ working to an abstraction api for the db / improving existing api methods to make it easier for the creators of SQLite plugins (like the ones mentioned above) or other db implementations, instead of siphoning off resources to work on something only beneficial to a (relatively) small subset of users.
zieladam 12:36 pm on September 17, 2022

Yes! I support this proposal! It could bring WordPress to places where MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. is not an option. Sure, there is a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party for that, but it’s not the same a official support. I’m contributing full-time and I only learned about that plugin a few weeks ago and by accident.
andronocean 9:00 pm on September 18, 2022

I am wholeheartedly in favor of a pathway to native SQLite support! Easily running a “lightweight” WP install would be a boon for non-technical users or anyone else who doesn’t want to take on the project of building and maintaining a toolchain for a “modern” static site. The “but how will users know which DB to pick?” question is a minor issue; have a WP support doc explaining the pros and cons, and the community will supplement with tutorials, install wizard questionnaires by hosts, migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. tools in the many DB migration plugins already available.

A tangential idea: one thing that could greatly help less-savvy users is if plugins in the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party repo could add a compatibility label reporting how well they will work on the installed database. Perhaps plugins could self-label as “Works fine on SQLite”, “Caution: may occasionally be slow”, and “Not recommended for use with SQLite”.

With all that said, however, I feel strongly that adding a database abstraction layer would the best approach to this. Having separate MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. and SQLite APIs (even at a low level) seems like a worrisome breeding ground for subtle incompatibility bugs, testing hassles, potential security issues. I also worry that it might encourage plugin devs to work with both database types directly if WP doesn’t provide good middleware — multiplying those problems further. Whereas a native, first-class ORM built into WordPress would highly encourage good dev practices, give site owners and developers more options, and provide a very interesting gateway to future capabilities (maybe, far down the road, a granular plugin permissions system where users must authorize a plugin to write to certain db tables).

I don’t doubt that as you said, this “would be a colossal task”. I’d like to see a thorough examination of what it would involve, though, maybe in a dedicated Make proposal so the options could be weighed conscientiously. I’d ask, if it’s something you’re probably going to need one day anyways, does the situation somehow improve later if you postpone it and build an SQLite-only option today?
Ari Stathopoulos 8:25 am on September 19, 2022
I don’t doubt that as you said, this “would be a colossal task”. I’d like to see a thorough examination of what it would involve, though, maybe in a dedicated Make proposal so the options could be weighed conscientiously. I’d ask, if it’s something you’re probably going to need one day anyways, does the situation somehow improve later if you postpone it and build an SQLite-only option today?

I can only speak based on my personal examination, research, and experiments so far:

I have not seen a working ORM implementation out there for WP.
So naturally, about a year ago I started looking at all available ORMs and researching which one to use. I soon came to the conclusion that the most suitable candidate for CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. would be Doctrine. It’s used by Laravel, Symfony, Drupal, and a lot of other PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher projects and CMSs. It is properly and constantly maintained, it has been battle-tested and just works.
After trying to integrate the ORM in WP, I realized that implementing a full-fledged ORM would require rewriting half our code, which can turn out to be a multi-year project.
I then scaled-down my ambitions, and started thinking that a database-abstraction layer would be more suitable for Core – and would not require rewriting everything. So I tried the Doctrine Database Abstraction Layer (DBAL). It made sense to use it, since in my mind it can be used as part of a grander plan to implement an ORM in a few years.
It is possible to implement the Doctrine DBAL, but again this would take a long time (I estimate 1-2 years). I don’t think the implementation itself will take more than 6 months, but testing will. The fact that a database-abstraction layer allows us to use multiple databases complicates things a lot, and we’ll need to test all possible scenarios for all databases supported.

Implementing SQLite on the other hand, is relatively simpler: We already have the code, and it’s been used for many years on production sites. If we commit to it, we can probably have it ready for production in WP 6.3 (personal estimation).

Once SQLite goes in, we can abstract the logic from both MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. & SQLite, and implement the Doctrine DBAL.
Once we implement the DBAL, we can then start thinking about an ORM.

But it has to be done in stages… We can’t go from zero to hero and expect things to just work.

SQLite is something that can solve a lot of problems now. It’s something that can help us figure things out. We can use SQLite to see how we’re going to define databases etc from now on. It’s a stepping stone for future implementations – and a necessary step towards a more abstract database system in the future because we’ll do a lot of the groundwork in order to implement it.
For example, while implementing SQLite, we may find ourselves thinking that instead of constants like this in wp-config:
```
define( 'DB_NAME', 'wordpress_develop' );
define( 'DB_USER', 'root' );
define( 'DB_PASSWORD', 'password' );
define( 'DB_HOST', 'mysql' );
define( 'DB_CHARSET', 'utf8' );
define( 'DB_COLLATE', '' );
```
maybe we should have a single one like this:
```
define( 'DATABASE_DRIVERS', [
	[
		'driver'   => 'mysqli',
		'name'     => 'wordpress_develop',
		'user'     => 'root',
		'password' => 'password',
		'host'     => 'mysql', 
		'charset'  => 'utf8',
		'collate'  => '',
	],
] );
```
Something like that would allow us to configure things properly for any DB-type. But we can’t have these discussions unless we have more than 1 database-types to work with…

I agree that long-term, an ORM would be the way to go. But the way I see it, it makes sense to do it in stages like SQLite → DBAL → ORM.
This way we’ll always have something stable, and iron-out the issues that may come up without falling on our sword.
We may or may not end-up with an ORM. We may or may not end up using a DBAL. But SQLite can help us take a necessary step forward no matter what the distant future holds.
- justlevine 9:52 am on September 19, 2022
  
  >I agree that long-term, an ORM would be the way to go. But the way I see it, it makes sense to do it in stages like SQLite → DBAL → ORM.
  
  I’m still unclear why this necessitates moving SQLite support directly to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. As you note:
  We already have the code, and it’s been used for many years on production sites.
  
  Why can’t we just skip the “SQLite Phase”, and use the basis of existing solutions to inform the implementation a “DBAL phase”?
  
  If we’re worried about relying on an external codebase for designing the api, it could always be stableized in a canonical pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, which seems imo seems perfect for this particular use case.
  - Ari Stathopoulos 10:14 am on September 19, 2022
    
    Why can’t we just skip the “SQLite Phase”, and use the basis of existing solutions to inform the implementation a “DBAL phase”?
    
    Because the SQLite implementation exists. It has been tested. We know it works, and has worked for 8+ years.
    DBAL has never been implemented by anyone (not due to lack of effort mind you). It has never been tested, and includes many more moving parts since it supports more than just MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. & SQLite. It is a lot more complex, and though in theory your assumption is correct, in practice it’s not that easy.
    DBAL is uncharted territory, while SQLite is not.
    
    That being said, if you have a working prototype with DBAL and WP, I’d love to see it, that would change the discussion completely.
    - justlevine 12:50 pm on September 19, 2022
      
      Sorry if I wasn’t clear. My question is why SQLite needs to be _in core_ , both altogether with no abstraction model, or as a prerequisite for working on an abstraction model…
      - Ari Stathopoulos 1:14 pm on September 19, 2022
        
        I understand that your opinion is it should be in a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, you have voiced that multiple times above and I can respect that… Even though I don’t agree. I won’t try to convince you, everyone is entitled to their opinion.
        As for why me personally – and a lot of other people believe it should be in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., I’m afraid I’ll have to answer that question with a question.
        Why should MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. be in Core? With the exception of historical reasons, the answer is the same. SQLite is not less or more important than MySQL. Historically WordPress was built with mysql because we inherited it, not necessarily because it was the best option. (Or maybe at the
        time it was just available and worked)
        
        From my perspective, a database engine/driver like mysql or sqlite belongs in core – which is why when you install WP you don’t have to go and also install a plugin for mysql.
    - justlevine 1:24 pm on September 19, 2022
      
      From the comments and discussions happening elsewhere, it seems there’s a lot of support for WP supporting different database types.
      
      An existing solution that adds SQLite support as you noted has existed for many years outside of coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and, the need for this specific database type doesn’t seem to jive with the 80-20 ‘decision not options’.
      
      The argument you seem to make is that an actual abstraction layer (full or partially) is too complex to implement right now, but by bringing SQLite into core, that will somehow become easier to implement. But I’m not seeing any justification for it.
      
      How would including SQLite support in core be different than continuing to rely on no the existing solutions?
      
      Why is including SQLite support in core preferable to supporting it with a canonical pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party?
      
      How does bringing SQLite into core get us closer to an abstraction model, that we couldn’t get by using the existing solution as an external reference or a canonical plugin to inform the api design decisions we need to make?
      
      Without clear answers to these, we’re just adding more bloat and committing contributor hours that -outside of GB – are already stretched super thin, no?
      - justlevine 1:32 pm on September 19, 2022
        
        Apologies, I wrote ^ before I saw you responded. I know both of us have made our opinion clear, and while I’m not looking for you to change mine, I’m asking for you to provide the _rationale_ for yours.
        I think your thoughts the 3 specific questions I posed in my last comment would move this conversation forward productively without placing the onus on you to actually change anyone’s opinion 🙏
Jonny Harris 10:31 am on September 20, 2022

I wonder if it would a good start to run the WP CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. unit tests in CI with SQLite. Enable the drop-in on a new CI workflow. This would go a long way to test if core works with SQLite.

I would also recommend mark the linked to drop-in, as a the canonical pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and promote it on the plugin repo.
Denis Žoljom 9:59 am on September 26, 2022

I realized I hadn’t commented on this post earlier. I for one really look forward to WP supporting SQLite out of the box.

Currently, I have a package that relies on the https://github.com/aaemnnosttv/wp-sqlite-db package for running integration tests with WordPress and PestPHP testing framework.

It would be great if I could get rid of that dependency and make everything work out of the box by just adding some config changes 🙂
batonac 9:49 am on September 28, 2022

I became aware of the existing driver through a recent article on WPTavern. I would love to see this in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.! Of course, it would need to be marked as BETABeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. for some time, but that’s becoming standard fare these days…
cck23 12:42 am on September 29, 2022

Hello. I too support this suggestion.

Our organization’s deployment method is to push a GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. repository for development to a production server, and for this reason we gave up using WordPress and used a flat file CMS.

A coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Sqlite implementation could be adopted by an organization like ours, simplifying server relocation and making CI cycles more efficient.
Terry J 7:54 pm on September 29, 2022

I have wanted SQLite coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. ability for years. In my world only a couple of my sites really need mySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/..

Please consider it.
rjasdfiii 3:53 pm on October 18, 2022

The current DB implementation has issues for large sites. I worry that SQLite users will fall into a similar abyss — start out small and all is well, then grow to where performance suffers. Can we prevent letting SQLite users from getting too big? I doubt it.

Meanwhile, WP is only now looking seriously at how to improve the DB performance in MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/.. Some, but not all, of those improvements can be carried over to SQLite. But, beware, for “big” WP sites, SQLite is likely to have unacceptable performance.
- Ari Stathopoulos 4:11 pm on October 18, 2022
  
  SQLite is very capable to handle enormous amounts of data – and in fact it does every day on millions of applications.
  There are some things that are worse, and some things that are better! Getting a single post out of thousands for example will be faster, while search will be slower.
  There’s no one-size-fits all solution. However, we should not do blanket statements like “SQLite is likely to have unacceptable performance”.. Not without sufficient data and real-life testing.
  - bukowa 12:11 pm on October 20, 2022
    
    What if we could have some basic implementation and start testing?
    - Ari Stathopoulos 6:21 am on October 21, 2022
      
      We’re already working on that in the performance-lab repository as a module on that pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.
      Soon, we’ll have something that everyone will be able to test 👍
      - bukowa 12:26 pm on November 1, 2022
        
        Thanks for reply, would you mind sharing some links?
        
        Ari Stathopoulos 12:47 pm on November 1, 2022
        
        Sure! You can find the pull-request here: https://github.com/WordPress/performance/pull/547