That works for relatively simple scenarios. When you have to add deploying sql changes or something having to update something in the cloud, you'd have to include a lot more plumbing.
Deploying SQL changes is actually trivial if you are using SQLite.
I agree in a hosted+shared SQL scenario you have to be a little bit more careful with all of this. Arguably, you should have a separate schema management phase in these cases.
But if you are just SQLite embedded in the service, you can use the user_version pragma to track schema version and perform deterministic migrations (assuming a user didn't manually jack with the file in-between).
In my world CI/CD and db migrations are 2 different things working together. CI/CD at heart is rather simple for many setups. Migrations need quite a lot scrutiny, you really want to mess up there. But if you run on gihub actions with 50/50 uptime, does it matter?
Deploying SQL changes? Why not just let the application do that on startup.
Ofcourse be backward and forward compatible. SQL change only deploy.
"Update something in the cloud" <- What do you mean?
loading story #48281082