simonwillisonblog-backup VS wp-sqlite-db

> I’ve been running that for a couple of years in this repo: https://github.com/simonw/simonwillisonblog-backup - which provides a backup of my blog’s PostgreSQL Django database (first converted to SQLite and then dumped out using sqlite-

I'm curious, what is the reason you chose not to use pgdump, but instead opted to convert to to sqlite and then dump the DB using sqlite-diffable?

On a project I'm working on, I'd like to dump our Postgres schema into individual files for each object (i.e., one file for each table, function, stored proc, etc.), but haven't spent enough time to see if pgdump could actually do that. We're just outputting files by object type for now (one tables, function, and stored procs files).

My personal blog runs on Django + PostgreSQL, and I got fed up of not having a version history of changes I made to my content there.

I solved that by setting up a GitHub repo that mirrors the content from my database to flat files a few times a day and commits any changes.

It's worked out really well so far. It wasn't much trouble to setup and it's now been running for nearly three years, capturing 1400+ changes.

I'd absolutely consider using the same technique for a commercial project in the future:

Latest commits are here: https://github.com/simonw/simonwillisonblog-backup/commits/m...

Workflow is https://github.com/simonw/simonwillisonblog-backup/blob/main...

If you really, really need to be able to see a SQL schema representing the current state, a cheap trick is to run an automation on every deploy that snapshots the schema and writes it to a GitHub repository.

I do a version of that for my own (Django-powered) blog here: https://github.com/simonw/simonwillisonblog-backup/blob/main...

My blog is Django and PostgreSQL on Heroku, but last year I decided I wanted a reliable long-term public backup... so I set up a scheduled GitHub Actions workflow to back it up to a git repository.

Bonus feature: since it runs nightly it gives me diffs if changes I make to my content, including edits to old posts.

The backups are in this repo: https://github.com/simonw/simonwillisonblog-backup

Before they added SQLite as WP plugin, I would use https://github.com/aaemnnosttv/wp-sqlite-db/ and I would use `define('DB_DIR', '/absolute/custom/path/to/directory/for/sqlite/database/file/');` to define the database location of my choice; I believe they would let users do the same with core support.

They basically took this implementation and just adapted it to coding standards:

https://github.com/aaemnnosttv/wp-sqlite-db

This has been around since some time and is itself a fork of a previous work.

The interesting part is that this drop-in replacement (mostly) already works well, there are a few issues that are related to some quirks in the WordPress core itself, for example: https://github.com/aaemnnosttv/wp-sqlite-db/issues/18

And maybe now they will be fixed.

Author here, here's an in-depth writeup on how this works and why it's useful:

https://make.wordpress.org/core/2022/09/23/client-side-webas...

To answer your questions directly:

WebAssembly is the magic sauce that transforms server-side code into client-side code. MySQL unfortunately is not yet supported by WebAssembly, so I applied a plugin that adds SQLite supports to WordPress [0]. The WebAssembly application has its own in-memory filesystem that lives in a specific browser tab and is scraped as soon as you close it.

So – technically it exposes db credentials, and even the entire DB, but that you are the only user of that DB so it's okay.

> What would the backend look like

The only backend is a static file server where the code and the database live. Your browser downloads a copy of the database and allows you to modify it in the current tab, but the updates are never saved back to the server.

[0] https://github.com/aaemnnosttv/wp-sqlite-db

1. Plugins that register their own database tables (however there already exists prior art such as https://github.com/aaemnnosttv/wp-sqlite-db for handling these cases)

2. Plugins that do direct queries against the standard database schema (broadly either for invalid (bad code) or performance (valid but slim use case) reasons)

Also, WordPress would of course keep the old query functions around and they would likely add a tag to the plugin repository so authors can mark plugins as supporting thes new ORM features.

Great idea in my opinion!

There's a WordPress plugin that adds support for SQLite as an alternative to MySQL.

Apparently it works really well. The implementation is (to my) simply astonishing: they run regular expressions against the SQL to convert it from MySQL dialect to SQLite! https://github.com/aaemnnosttv/wp-sqlite-db/blob/9a5604cce13...

This wp-sqlite-db one. Not super active, but maintained, at least.