Original Summary

I'm a solo dev. Last week I moved my new clients SaaS to a new architecture and it took me about 7 hours of planned downtime. The app is 3DPCC, a cost calculator and production tool for 3D print shops. New frontend, new Node backend, same Supabase project underneath, but all the existing user data had to land in a different structure. I didn't even try to do it live. The old frontend talked straight to Supabase, so putting up a maintenance page would have changed nothing. Someone could still have saved a record into the old structure while I was halfway through rewriting it. So I froze writes with triggers on every public table. Auth and Storage are Supabase's own thing and I couldn't freeze those safely, so I worked around it: registration off, crons paused, direct uploads blocked. The part that genuinely surprised me was where the hours went. Roughly 70% of the window was just running the migration and mapping scripts and then sitting there checking whether the output made sense. The actual deploy was a footnote. I had sized the whole window around the deploy, which was the wrong anchor. Next time I'm estimating from how much data there is and how many things I expect to have to repair. Three things I'd do again without thinking: I rehearsed a backup restore on a local Postgres a few days earlier, so I already knew it takes under a minute. That took the restore off my list of scary things. I had someone review the plan, and they talked me out of auto-fixing duplicate SKUs by appending suffixes. Turns out a lot of users treat that field as a material label, not an SKU, so the script would have quietly rewritten what their data meant. I'd have never caught that on my own at 2am. I tested reads while the freeze was still on, and only lifted it once those were clean. Then tested writes. The stage that actually fought back was setting up the production environments. Everything else held. The only warnings were ones I'd already expected, around inventory records with incomplete data. I wrote up the details (the freeze, the backup script, the rollback plan) here: https://appcrates.pl/en/blog/3dpcc-production-migration-7-hours-downtime For those of you with real users on the line: do you plan a downtime window for this kind of thing, or do you push for zero downtime even when it means a lot more moving parts? And how do you actually estimate the window? Disclosure: I built 3DPCC and wrote the linked post.   submitted by   /u/Illustrious-Code-674 [link]   [comments]

  • 情报分类：商业与市场研究
  • 分类依据：内容涉及商业、投资或市场动态
  • 信息来源：Reddit · SaaS
  • 发布时间：2026/9/30 19:35:16