4 ms·

I don't know what SQLite has gotten over a 5 line docker-compose.yml running PG locally for my project. It's ready for scale-up when needed, supports more featu

by fb03 3y ago

I don't know what SQLite has gotten over a 5 line docker-compose.yml running PG locally for my project. It's ready for scale-up when needed, supports more features and foreign keys without setting a flag manually, proper types etc. I get SQLite for mobile and toy projects but really, a PG set up in docker-compose.yml in your project is the easiest thing to do these days.

TehShrike 3y ago
"no docker" is a huge selling point for me
- fb03 3y ago
  Can you expand on that? my use case is pretty simple and I haven't been able to find something on it that really bothers me. Also, about PG: I run each project in a different port. Not defaulting to PG's default 5432 makes it able to easily run several projects at once without clashing, just like you would with several SQLite files. I don't really see any drawbacks in using a little docker compose for your local dev set-up.
  - TehShrike 3y ago
    > Can you expand on that? I spent a little time trying to learn docker fundamentals and it was so obtuse and broad that it really scared me off. I like containers in theory, but I'm not huge on the overhead of VMs, and I'm leery of getting such a complex tool involved with my deployments.
    - fb03 3y ago
      I see. Thank you for the reply. For something as simple as having your own little DB side by side to your project, it is really not that complicated. A 5 line docker-compose.yml gets you a fully encapsulated PG instance on a custom port. One per project. I hope you give it a try someday if you get the chance - also, it's a process in a "jails"-like environment, not a VM, not another full blown kernel running - so really the performance overhead is minimal to none - just like if you were running PG "locally" (well, you actually are)