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.
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.
Of course - there are exceptions (gdpr deletion rules etc)
There's novel lessons to be learned in tech all the time.
This is not one of them.
OPS: Huh, it appears we can't find your incremental.
ME: Well just restore the weekly, its only Tuesday.
Two Days later.
OPS:About that backup. Turns out it's a backup of the servers, not the database. We'll have to restore to new VM's in order to get at the data.
ME: How did this happen?
OPS: Well the backups work for MSSQL Server.
ME: This is PostgreSQl.
OPS: Yeah, apparently we started setting that up but never finished.
ME: You realize we have about 20 applications using that database?
OPS: Now we do.
Lesson: Until you personally have seen a successful restore from backup, you do not have backups. You have hopes and prayers that you have backups. I am forever in the Trust but Verify camp.
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.
They were extremely lucky. Imagine what the boss would have said if they hadn't managed to recover the data.
> I immediately messaged my co-founders.
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.
"Picture this: Panic mode activated. You heard that right. But here's what surprised me the most" and so on. Ugh.
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.
lol good luck op
Also, “on delete restrict” isn’t a bad policy either for some keys. Make deleting data difficult.
I actually agreed 100% with this learning, especially the last sentence. The younger me would write a long email to push for ON DELETE CASCADE everywhere. The older me doesn't even want to touch terraform, where an innocent looking update can end up destroying everything. I will rather live with some orphaned records and some infra drifts.
And still I got burnt few months ago, when I inadvertently triggered some internal ON DELETE CASCADE logic of Consul ACL.
(I do agree with your other points)
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!
Your Joe AI customers should be worried. Anyone actually using the RankBid you did a Show HackerNews on 8 months ago should be worried (particularly by the "Secure by design: We partner with Stripe to ensure your data is secure." line.
If you don't want to get toasted by some future failure where you won't be accidentally saved by a vendor, then maybe start learning more on the technical side instead of researching and writing blogspam like "I Read 10 Business Books So You Don't Have To".
This might sound harsh, but it's intended as sound advice that clearly nobody else is giving you.
This was not the case of Joe AI. I joined later in the project, and the foundations where even weaker than what is shown in this newsletter (no API endpoint authentication whatsoever, open bar, for example) and so I had to secure and migrate everything myself when I joined them. This was what the Supabase migration was trying to accomplish. Before I joined, they didn't even have a database but I won't get into the details here.
Before Rankbid, and the other products I've built, I've worked at a B2C startup with millions of users and never caused a big outage there, I've been programming for more than ten years, and I have a double degree in computer science, and while I agree with what "should be done" in theory for production level apps, sometimes, you need to move very fast to build great startups. I've read many technical books in my life such as Designing Data Intensive Applications, High Performance Browser Networking. I know the theory, but sometimes you just don't have the time to do everything perfectly. That's what I try to expose in this blog post. I also wanted to share a humbling experience. Everyone makes mistakes, and I'm not ashamed of making some, even after years of software engineering.
My newsletter is about the intersection of programming and business. You might not find the "business" part interesting which is fine, but I think what you call blogspam has real value for engineers who have never sold before in their life and want to learn the ropes. I spend a lot of time writing each edition, because I try to respect the time of my readers as much as possible to deliver some actual insights (even if there is a bit of fluff or story telling sometimes).
And for Joe AI: it has since become much more secure, and is progressively implementing engineering best practices, so customers don't have to worry.
"I had just finished what I thought was a clean migration: moving our entire database from our old setup to PostgreSQL with Supabase" ... on a Friday.
Never do prod deploys on a Friday unless you have at least 2 people available through the weekend to resolve issues.
The rest of this post isn't much better.
And come one. Don't do major changes to a prod db when critical team members have signed off for a weekend or holiday.
I'm actually quite happy OP posted their experiences. But it really needs to be a learning experience. We've all done something like this and I bet a lot of us old timers have posted similar stories.
The technical takeaway, as others have said, is to do prod deployment during business hours when there are people around to monitor and to help recover if anything goes wrong, and where it will be working hours for quite a while in the future. Fridays are not that.
Thats not very profitable
> Here's the technical takeaway: Never use CASCADE deletes on critical foreign keys. Set them to NULL or use soft deletes instead. It's fine for UPDATE operations, but it's too dangerous for DELETE ones. The convenience of automatic cleanup isn't worth the existential risk of chain reactions.
What? The point of cascading foreign keys is referential integrity. If you just leave dangling references everywhere your data will either be horribly dirty or require inconsistent manual cleanup.
As I'm sure others have said: just use a test/staging environment. It isn't hard to set up even if you are in startup mode.
Not quite. Databases can enforce referential integrity through foreign keys, without cascading deletes being enabled.
“On delete restrict” vs “on delete cascade” still enforces referential integrity, and is typically a better way to avoid the OP’s issue.
We’re just getting started and we’re even in Supabase’ paid plan.
That being said, I would love to see more resources about incident management for small teams and how to strike this balance. I'm the only developer working on a (small, but somehow super political/knives-out) company's big platform with large (F500) clients and a mandate-from-heaven to rapidly add features -- and it's by far the most stressed out I've ever been in my career if not life. Every incident, whether it be the big GCP outage from last week or a database crash this week, leads to a huge mental burden that I have no idea how to relieve, and a huge passive-aggressive political shitstorm I have no idea how to navigate.
no backups? perfect. now you'll never forget to set one up again. friday night? even better. you got the full rite of passage.
people act like this's rare. it’s not. half of us have nuked prod, the other half are lying or haven't been given prod access yet.
you’re fine. just make the checklist longer next time. and maybe alias `drop` to `echo "no"` for a while
cranberryturkey•7mo ago
grepfru_it•7mo ago
cranberryturkey•7mo ago