Re:Why you should probably be using SQLite
by geraldwhen on Friday October 27, 2023 @10:44AM
(#38039120)
You will run into compatibility issues almost immediately. Running a local Postgres container is really the only option.
Re:Why you should probably be using SQLite
by time0ut on Friday October 27, 2023 @11:06AM
(#38039452)
My general pattern these days is a compose file with postgres and another container to run my migrations (along with anything else I need). Then I have an integration test suite that hits all the code paths that touch the database. The whole workflow gets run again in CI but with the new image via a profile in my compose file. Its so fast and easy to do at this point.
Re:Why you should probably be using SQLite
by captn3m0 on Friday October 27, 2023 @12:09PM
(#38040368)
Managing Postgres, even via containers is not so simple. Upgrades between major versions will still need a backup+restore for eg.
I run a single container Postgres for my homeserver, and have to deal with occasional issues that wouldn’t apply to SQLite (which I run as well).
I mean this is more of less what using a local container for Postgres is. It’s not exactly one file but it’s hidden in a volume somewhere where you don’t need to go file digging, so for all intents and purposes sure, it’s one file.
Most ORMs also will let you swap out your RDBMS so you can run sqlite locally and Postgres in prod via the same code. I think this is a bit of an anti pattern though. While the two are similar in most standard use cases, it’s not always apparent when you veer off that standard use case and into something that’s not supported by sqlite. And then all of the sudden you either have a divergence between what works locally vs in production or you start to intentionally limit your app’s capability to only what works with sqlite because you can’t locally validate it.