5 ms·

I think it's a good compromise. You're accepting a lot of looseness and fault-tolerance on the application side, but you have guaranteed safety of your underlyi

I think it's a good compromise. You're accepting a lot of looseness and fault-tolerance on the application side, but you have guaranteed safety of your underlying data. What scares me more than anything else is lost / compromised / invalid data. That's hard to fix. The frontend code is straightforward to fix, relatively speaking.

smashah 6y ago
I forgot to mention this was at a startup on ground level. Regular data backups always soothes my nerves. Eventually it makes sense to have type/db strictness on both app and db side however it just felt like wading through quicksand with a small team where we should be sprinting and db structure is fluid and ever changing
- aidos 6y ago
  When you have the tooling in place, it’s relatively easy to remodel your data in Postgres. I use alembic (python), so most of the schema changes are handled for me - and then I need to write any updates to fill in the gaps. It doesn’t matter what you’re using though, if you’re restructuring data, you need to handle the changes yourself to get from one consistent state to another. Postgres allows you to do this so you you don’t end up in some horrible halfway house where you’ve kinda migrated, but kinda not because you missed something. DB level constraints are the best, especially when you have a bunch of legacy data to worry about.