3 ms·
Why would you want to switch databases when you deploy? That's asking for bugs that only get revealed in production. Also, the intersection of SQLite, MySQL, a
by rspeer 11y ago
Why would you want to switch databases when you deploy? That's asking for bugs that only get revealed in production.
Also, the intersection of SQLite, MySQL, and Postgres is a pretty terrible database. You can be a lot more effective if you decide which one you're writing for.
- drdaeman 11y agoHey, wait. We don't even have a project defined but you're already talking about being effective. Isn't it a bit early? ;) A lot of CRUD apps (which, I think, a lot of websites/webapps are) don't usually use anything but the basic SQL stuff.
- ForHackernews 11y ago> Why would you want to switch databases when you deploy? That's asking for bugs that only get revealed in production. Only if you deploy directly to production! Any competent organization should have at least a staging environment (and probably some other pre-staging testing environments) where you deploy and run your full application stack, and only promoted verified builds to production after they pass QA on earlier environments.
- ta0967 11y agothe top-level comment in this thread praises SQLAlchemy for being "cross-database, so you can use the same code with SQLite for development, and deploy to MySQL or Postgres.", and your parent just says that's a recipe for disaster.
- ForHackernews 11y agoIt's pretty common to run SQLite on your local machine while developing. Apparently the parent is confused by reading "deploy" as "deploy directly to production".
- zzzeek 11y agotargeting both MySQL and Postgresql is very reasonable and is commonplace. Openstack does it, for example. Lots of apps do. This assumes you're doing an app that's mostly CRUD. If you're doing a BI kind of app and need fancy analytical functions, then yes you'd target Postgresql.