Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Developing directly on the production database with no known backups. Saved from total disaster by pure luck. Then a bunch of happy talk about it being a "small price to pay for the lessons we gained" and how such failures "unleash true creativity". It's amazing what people will self-disclose on the internet.


That's the first thing I took away. The author ignores every sane software engineering practice, is saved by pure luck and then dives into what commands not to use in supabase. Why do this? Why not spend a week or two before you launch to setup a decent ci/cd pipeline? That's the real lesson here.


I cut my dev teeth in a financial institution so I'll concede I'm biased away from risk, but devving directly on the prod DB, not having a local enviroment to test changes against, and worse: literally no backups.. it screams wreckless, stupid, cheap, arrogant, and immature (in the tech sense). Nothing I'd like my name against publicly.


A colleague upgraded the production database for a securities financing settlement system on a Friday evening by accident 20 years ago.

We were devs with root access to production and no network segregation. He wanted to upgrade his dev environment, but chose the wrong resource file.

He was lucky it was a Friday, because it took us the whole weekend working round the clock to get the system and the data to a consistent state by start of trading.

We called him The Dark Destroyer thereafter.

So I would add network segregation to the mix of good ideas for production ops.


I’m building my toy project and I have an LTO drive taking backups every night. Here I am complaining that having 2Tb of backups is too much.

lol good luck op


Right?! This whole post is kinda absurd. It has the feel of a kid putting a fork into an outlet, getting the shock of a lifetime and then going “and thanks to this, everyone in my household now knows not to put a fork into an outlet.” You didn’t have to go through all this to figure out that you need backups. The fluff is the cherry on top


Maybe the post is an attempt to save face in front of his colleagues. Owning up to the mistake and listing lessons learned.


Yeah. Imagine everything else that's completely wrong in that app.


While I agree with everything said here about making backups etc. and which I have done in my career at later stage companies, when you are just starting out and building MVPs, I'd argue (as I do in the newsletter) that losing 2 weeks to setup CI/CDs pipelines and backups before you can pay the rent is a waste of time! I was a Supabase noob back then so I had not explored their features for local development, which is the learning I try to share in this post.




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

Search: