The “and honestly?” phrase smells like AI writing to the point I stopped there and closed the post. Don’t fuck your database up and do have point-in-time rollbacks. No excuses it’s not hard. Not something to be proud of.
Yeah, the whole thing is full of AI-isms. Started skimming and every other sentence has one. "Picture this: Panic mode activated. You heard that right. But here's what surprised me the most" and so on. Ugh.
I Dropped the Production Database on a Friday Night
61–67 of 67 posts
Re: I Dropped the Production Database on a Friday Night
#62Earlier quoted context omitted.
supabase kiinda pushes you in that direction though.
I agree. They also push you not to git migrations at first, which is definitely not the best practice.
We do not push devs not to do migrations - we would strongly prefer if everyone used migrations and declarative schemas.
Especially at the scale that OP is at (see maturity model: https://supabase.com/docs/guides/deployment/maturity-model)
Re: I Dropped the Production Database on a Friday Night
#63Earlier quoted context omitted.
I agree. They also push you not to git migrations at first, which is definitely not the best practice.
(Supabase ceo) We do not push devs not to do migrations - we would strongly prefer if everyone used migrations and declarative schemas. Especially at the scale that OP is at (see maturity model: https://supabase.com/docs/guides/deployment/maturity-model )
In particular, webhooks and triggers don’t work out of the box. So maybe it’s not pushing in a particular direction but at least I’d argue it’s not nudging you to do it because it entails some hours of custom setup and debugging before the CLI commands like supabase db diff actually work as intended in my experience. But I know the Supabase team is improving it every release so I’m thankful for this work!
Re: I Dropped the Production Database on a Friday Night
#64I hope the poster will learn about transactions at some point. Postgres even lets you alter the schema within a transaction. What I learned, once upon a time, is that with a database, you shouldn't delete data you want to keep. If you want to keep something, you use SQL's fine UPDATE to update it, you don't delete it. Databases work best if you tell them to do what you want them to do, as a single transaction.
I mean UPDATE users SET name='test' is still effectively a delete...
This is a kind of misunderstanding I've heard from others who were first exposed to hacky things like early mysql. Databases are something else. A different kind of beast. If you use a database, and Postgres is the best of the DBMSes, then you can say things like "a lead shouldn't be deleted before three months have passed, no matter what" or "a lead can't be deleted until its state column says it's been handled" and the DBMS will make sure of it. If you have a bug that would involve leads being deleted prematurely, the DBMS will reject your change. Your change just won't break the database.
Re: I Dropped the Production Database on a Friday Night
#65Earlier quoted context omitted.
Here is another one: Don't trust ops when they say they have backups. I asked and was told there are weekly full backups, with daily incrementals. The time came when I needed a production DB restored due to an upgrade bug in our application. That was bad - thank $DEIITY we have backups. OPS: Huh, it appears we can't find your incremental. ME: Well just restore the weekly, its only Tuesday. Two Days later. OPS:About t…
If your company is big enough to have dedicated ops then it should be running regular tests on backups. A disaster recovery process if you will. At some point though its not your problem when the company is big enough. Are you gonna do everyone's job? You tell em what you need in writing and if they drop the ball its their head.
The lack of working backups made it a problem because if assurances and certifications we were required to maintain.
When starting a new project I now request a dev database with a dump from prod more than 30 days ago just to see the process work. Does it waste their time? Maybe. In which case it encourages more automation. Do I care no? But I am not getting burned again.
Re: I Dropped the Production Database on a Friday Night
#66Earlier quoted context omitted.
> I learned that day that running automated tests on a production database isn’t a good idea! There's novel lessons to be learned in tech all the time. This is not one of them.
Learn lessons from other people. You can't learn them all yourself.