Hacker News new | past | comments | ask | show | jobs | submit login

Yeah for development Postgres is easy to install. For deployment it comes at a complexity cost.

I have small scripts that do things like send an email on a given business event. These scripts pull data from the main ERP. To keep the system upgradable we avoid changes to the ERP's database. So these scripts need their own DB to store state, such as when the email was sent. At first this involved one Postgres instance with databases for each script or application. If that Postgres server moves IP or has a version upgrade often every script or app needs a config change or library upgrade. Everything gets coupled together. By using an SQLite DB per script a range of problems go away. Of course anything that has multiple users or needs to be reported on has to go into a central DB but a surprising amount can happly run on it's own independent SQLITE DB.

To move hosts or backup the application and DB you take a copy of the folder. It's so easy.




Oh sure. Nothing against SQLite. If your needs are simple then it's a great solution. It's the "Postgres/MySQL in production, SQLite for development/testing" pattern that puzzles me.


Ah right yeah, I'm not sure that is a great idea. If you don't develop against the same system you want to deploy with you are asking to find bugs in production.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: