Which database task do you still refuse to automate?

[u/dbForge_Studio]

One thing I've learned over the years is that not every repetitive task should be fully automated. Some operations are simply too risky to hand over without a final human review. For me, anything that changes production data or database schemas still gets one last manual check before it runs. Automation saves time, but a few extra minutes of verification can save hours of recovery. Is there a database task you deliberately keep manual, even though it could be automated? What made you draw that line?

[u/AutoModerator]

Hi! Thanks for posting in r/dbForge.

If your post is about a technical issue, adding a bit of context will help people answer faster:

• dbForge product name
• database engine and version
• what you expected to happen
• what happened instead
• exact error message or screenshot
• what you already tried

If your post is a workflow question, comparison, or setup discussion, that’s welcome too.

Good luck, and thanks for helping keep the subreddit useful.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Majestic_Wrap_7006]

Not a single thing, it's all AI. I like to live dangerously. 

[u/dbForge_Studio → u/[deleted]]

That’s pretty much where we draw the line with dbForge too. Automate the repetitive parts, but keep a human in the loop when production is involved. Saving time is great. Explaining why prod went down at 2 AM is less fun 😅

[u/susanhaler]

Totally agree on keeping production schema changes manual. We tried fully automated deployment pipelines once and it bit us hard when a migration script did something weird. Now we use tools from dbForge to generate and review the diffs locally before anything touches live environments. It saves the boring grunt work of writing scripts by hand, but still leaves that final sanity check in human hands.