Bean & Bark: change data without losing it

View .md

Chapters one and two, you read. This one you write — and you write against production, where a wrong WHERE clause doesn't cost you a few RCU, it costs you data. Two things stand between you and a very bad afternoon: your prod stage is read-only until you say otherwise, and every bulk write shows you what it would do before it does it.

You'll learn
  • Understand why a prod stage is read-only by default, and how you consciously unlock a write
  • Use a preview-first bulk write to see every row that would change — before a single one does
  • Take a backup as a one-line seatbelt before any risky change

In production, look before you leap

The obvious write is one line, and it reads as perfectly safe. But you're pointed at prod, and Status = 'dormant' may match more than the subscriptions you have in mind. DynoStudio assumes you might be wrong: the prod stage refuses writes until you deliberately unlock it, and a bulk write is preview-first — it runs the match, tells you exactly how many rows it would touch, and writes nothing until you look and confirm.

sql 
-- looks harmless. it is pointed at PRODUCTION.UPDATE "BeanAndBark"SET Status = 'retired'WHERE Status = 'dormant'
Try it · preview the cleanupSample
Run it live in DynoStudio →
Executes asBulk UPDATE · preview · BeanAndBark
Scan FilterExpression: Status = 'dormant' → 4,012 matched · preview only, nothing written
"dormant" isn't only a subscription state — inactive customer accounts carry it too.
The preview is the whole point: 4,012 is not the ~200 you meant, so you stop here — before any write.
Preview · 4,012 rows would change — 214 subscriptions + 3,798 customer accounts. Retiring accounts would lock real customers out. ⚠ Nothing has been written.

That first preview is this whole chapter. Status = 'dormant' matched 4,012 rows — and 3,798 of them were customer accounts you'd have quietly retired, locking real people out. You wrote nothing; the preview caught it. Pin the write to subscriptions with begins_with(sk, 'SUB#') and the number drops to 214 — the set you actually meant. A Scan found them either way; the difference is that DynoStudio made you look at the blast radius first.

Recap
  • A prod stage is read-only by default — writes are refused until you consciously unlock it, so nothing changes production by accident.
  • A bulk write is preview-first: it shows every row it would change and writes nothing until you confirm — a too-broad WHERE is a number on screen, not lost data.
  • Take a BACKUP before a risky change. One line, cheap, and it turns any mistake into an undo.
Before you touch prod — check yourself2
You run a bulk UPDATE. Before anything in the table changes, what does DynoStudio show you?
The preview shows 4,012 rows when you expected ~200. What's the safe move?
Try it yourself 2
1 Scope the cleanup
Rewrite UPDATE "BeanAndBark" SET Status = 'retired' WHERE Status = 'dormant' so it can only ever touch subscriptions.
In a single-table design, the sk prefix is the entity discriminator. Subscriptions start with SUB#.
Show solution
Add begins_with(sk, 'SUB#') to the WHERE — now the match is pinned to subscription items, and customer accounts with the same Status are excluded.
sql 
UPDATE "BeanAndBark"SET Status = 'retired'WHERE begins_with(sk, 'SUB#') AND Status = 'dormant'
2 Take a restore point
Before applying any of this to production, write the statement that gives you a way back.
One statement snapshots the whole table on demand — no PITR setup required.
Show solution
A BACKUP TABLE snapshot is your undo. Run it, note the returned ARN, then apply the scoped write knowing you can restore.
sql 
BACKUP TABLE "BeanAndBark" AS 'beanandbark-pre-cleanup'
Was this page helpful?