Using SQLite integration as a layer to store/load wordpress posts from file system files via vtab (e.g. posts would correspond to files in `wp_posts` directory)

Supporting SQLite might also unlock transparent storing/loading wordpress posts (wp_posts table) in bare file system files (akin to Jekyll and other SSR blog engines) and using SQLite vtab (virtual table extension - I think something based on fsdir might work) mechanism for abstracting this away. This would allow for simpler interop with other blog engines (especially for small installations), especially when combined with some Markdown plugin

Likely fsdir would need to be forked/rewritten to adapt the column names to existing wp_posts DDL

And also "eponymous virtual tables" can be of use to completely mimic the wp_posts table even without a CREATE VIRTUAL TABLE command: https://www.sqlite.org/vtab.html#epovtab

In a similar way, a vtab can be created to back wp_options table with a single JSON/YAML file on disk (wp_options.json or wp_options.yaml)

I've tried asking DeepSeek to write code for such two vtab extensions (wp_posts and wp_options) and produces something reasonable and even not too much code. I assume there would be nuances (not sure if then indexes can be created for such vtabs and if it would break anything else in WordPress), but it seems viable

Start with SQLite's ext/misc/fileio.c fsdir implementation and the virtual-table and eponymous virtual-table documentation linked in the issue. Compare the existing wp_posts and wp_options schemas, then determine whether file-backed virtual tables can preserve WordPress compatibility, including the proposed posts directory and JSON/YAML options files. Done means the scope, compatibility constraints, and required extensions are validated.