Create a SQLite-backed Durable Object, query it with ctx.storage.sql, and schedule reliable recurring work with alarms

Documented steps

1. In wrangler config, create the class with a SQLite migration — `[[migrations]] tag = "v1" new_sqlite_classes = ["MyDurableObject"]` — NOT the legacy `new_classes`. Add a matching `[[durable_objects.bindings]]` entry with `name` and `class_name`.
2. Define the class extending `DurableObject`. In the constructor, wrap initialization in `ctx.blockConcurrencyWhile(async () => { ... })` so in-memory state is rehydrated from storage before any request is served, preventing cold-start and post-hibernation races.
3. Run SQL with `ctx.storage.sql.exec(query, ...bindings): SqlStorageCursor`, using `?` placeholders: `this.ctx.storage.sql.exec("SELECT * FROM artist WHERE artistname = ?;", "Alice").one()`.
4. Create schema the same way: `ctx.storage.sql.exec("CREATE TABLE IF NOT EXISTS artist (id INTEGER PRIMARY KEY, name TEXT);")`. Multiple semicolon-separated statements are allowed in one exec(), but bound parameters apply only to the last statement.
5. Consume the cursor with `for (let row of cursor)`, `.toArray()`, `.one()` (throws unless exactly one row), or `.raw()` for array-shaped rows. The cursor also exposes `columnNames`, `rowsRead`, and `rowsWritten` — use those for billing and query debugging.
6. Fully consume a cursor synchronously before your next `await`. A partially-read cursor spanning an await boundary breaks the storage API's snapshot-isolation guarantee.
7. Do not issue `BEGIN TRANSACTION` or `SAVEPOINT` through exec(). Use `ctx.storage.transaction(async () => {...})` or `ctx.storage.transactionSync(() => {...})` for atomic multi-statement work.
8. Schedule a wakeup with `ctx.storage.setAlarm(epochMillis)`. Calling it again overwrites any pending alarm. Read the pending time with `ctx.storage.getAlarm(): number | null` and cancel with `ctx.storage.deleteAlarm()`.
9. Implement the handler on the class: `async alarm(alarmInfo?: { retryCount: number; isRetry: boolean }) { ... }`. Cloudflare invokes it at or after the scheduled time with at-least-once guaranteed execution.
10. Know the retry ceiling: an uncaught exception in alarm() is retried with exponential backoff starting at 2 seconds, for up to 6 retries, then abandoned. For jobs that must never be dropped, catch the exception yourself and call setAlarm() again to reschedule.
11. For a self-perpetuating recurring job, set the next alarm from inside alarm() and also check `getAlarm()` before calling setAlarm() in the constructor — the constructor reruns on every reactivation and would otherwise clobber a pending alarm.
12. To stop being billed for a Durable Object's storage you must call BOTH `ctx.storage.deleteAll()` and `ctx.storage.deleteAlarm()`.
13. Choose SQLite-backed DO storage when you want compute colocated with data (lower latency, point-in-time recovery); choose D1 when you need a separately managed database reachable over the network from many Workers.
14. Official documentation (verify before relying on limits, which change): https://developers.cloudflare.com/durable-objects/api/sql-storage/ | https://developers.cloudflare.com/durable-objects/api/alarms/ | https://developers.cloudflare.com/durable-objects/best-practices/access-durable-objects-storage/ | https://developers.cloudflare.com/durable-objects/platform/limits/