The Playground stores more than the SQLite database in OPFS. This includes things like installed plugins and file uploads and other artifacts brought in during boot. If there's enough interest and time I could imagine support being added to separate these, but for now it's easiest to have a single load and store mechanism for everything.

There's a third option supported only in Chrome at the moment which loads a directory from your computer's filesystem, bypassing even OPFS.

> using OPFS directly from SQLite doesn't work?

not entirely following your question. any way you could reword and explain what you were hoping to accomplish?

> Is there a reason why using OPFS directly from SQLite doesn't work?

I'm guessing this means using SQLite WASM's built-in OPFS integration as described in these articles:

- sqlite3 WebAssembly documentation - Persistent Storage Options: OPFS - https://sqlite.org/wasm/doc/trunk/persistence.md#opfs

- SQLite Wasm in the browser backed by the Origin Private File System - https://developer.chrome.com/blog/sqlite-wasm-in-the-browser...

Within the Playground, SQLite interacts with the database file in MEMFS only, and the Playground coordinates the syncing from MEMFS to OPFS.

https://github.com/WordPress/wordpress-playground/tree/trunk...

The reason for this, I believe, is that the primary use case is/was to have the entire file system in memory, including SQLite's database file. This was the original implementation, and is still the default behavior. Persistence was later added as an optional feature.

The good news is that browser support for OPFS seems to be getting better. From the SQLite docs:

  As of March 2023 the following browsers are known to have the necessary APIs:

  - Chromium-derived browsers released since approximately mid-2022
  - Firefox v111 (March 2023) and later