Workspace storage: Durable Object SQLite or D1 per tenant #7

Activity

1. hammadmajid

   added

   wayfinder:researchWayfinder research taskWayfinder research task

   on Sep 3, 2026
2. hammadmajid

   added a parent issue on Sep 3, 2026

   • Server architecture: the walking skeleton #3
3. hammadmajid

   marked this as blocking on Sep 3, 2026

   • Workspace storage in a Durable Object #14
4. hammadmajid commented on Sep 4, 2026

   

   hammadmajid

   on Sep 4, 2026

   CollaboratorAuthor

   More actions

   Summary

   • A Durable Object per workspace, using ctx.storage.sql, is viable with Drizzle's drizzle-orm/durable-sqlite driver — schema, migrate(), and query builder all exist and are documented.
   • DO SQLite storage: 10 GB per object cap, 30-day point-in-time recovery via bookmarks, storage billing starts January 2026 (row reads/writes + GB-month), and a soft throughput limit around 1,000 req/s per object.
   • Routing is idFromName(workspaceId): deterministic, same id always reaches the same object, no lookup table needed — this is strictly simpler than D1's per-tenant binding problem.
   • WebSocket Hibernation (state.acceptWebSocket) coexists with SQLite storage on the same object; hibernation stops duration billing while connections stay open, so realtime is not precluded.
   • @cloudflare/vitest-pool-workers exercises real Durable Objects (not mocks) via runInDurableObject, listDurableObjectIds, runDurableObjectAlarm, and evictDurableObject — including real SQLite storage.
   • D1 is explicitly designed by Cloudflare for "per-user, per-tenant or per-entity databases" (10 GB cap each, up to 50,000 databases/account on Paid), which is direct primary-source backing for the named fallback.
   • The blocker for D1-per-tenant is binding, not storage: Workers bindings are static, injected at deploy time from wrangler.jsonc/the Workers API — there is no documented runtime API to bind a new D1 database to a live Worker without a redeploy. A per-tenant D1 Worker must either redeploy on every signup or drop bindings for the D1 HTTP/REST API (POST /accounts/{id}/d1/database/{db}/query), which is a network call, not a binding read.
   • The import { env } from "cloudflare:workers" rule (module-scope binding read, no per-request threading) holds for D1-per-tenant only if the binding set is static; it breaks the moment tenant creation needs a new binding without redeploying.
   • The Durable Object shape has no such problem: env.WORKSPACE_DO is one static namespace binding read once at module scope, and idFromName(workspaceId) — computed per request from ExecutionContext/the request path, same as any per-request logic — selects the tenant. This fits the bindings rule cleanly; D1-per-tenant does not.
   • Recommendation: Durable Object per workspace with SQLite storage, matching decision already recorded in issue Server architecture: the walking skeleton #3's Notes; shared D1 with workspace_id stays the fallback exactly as named.
   • What would make the prototype fail: Drizzle's DO SQLite driver missing DDL/relational-query support found live in code (a known 2024 GitHub gap, not yet confirmed resolved), a workspace needing to cross the documented per-object 10 GB or ~1,000 req/s ceiling, or packages/db's workspace-scoping and sequence conventions not translating cleanly onto per-object storage.

   Full findings: https://github.com/kryft-dev/prismark.tech/blob/research/workspace-storage/docs/research/workspace-storage.md
5. hammadmajid

   closed this as completedon Sep 4, 2026