Design a database sharding/tenant-partitioning strategy

[JSONbored]

Problem: A single database binding serves everything today — no sharding or tenant-partitioning strategy exists.

Area: ORB / Scaling

Proposal: Design (and where feasible, implement) a partitioning strategy that keeps per-tenant data separable and independently scalable.

Deliverables:

• A written partitioning design, plus an initial implementation if the design is straightforward enough to build directly.

AMS Cloud Readiness cross-reference (added 2026-07-12)

See also #5223 in the new AMS Cloud Readiness milestone (#28) — the AMS-side parallel to this exact problem, already citing this issue as precedent. Keep both sides in sync if either design changes.

[linear-code]

JSO-3563

[JSONbored]

Superseded — the decided tenancy model for hosted ORB is logical per-tenant scoping on a shared Cloudflare D1 database (see #4885/#4886/#4888/#4889), not physical DB sharding/partitioning. Closing; reopen if real scale ever demands a sharding strategy beyond what tenant-scoped D1 + indexes can handle.

[JSONbored]

Correction to my own closing comment above: the actual decided model is per-tenant isolated Cloudflare Containers (each with its own Postgres DB), not a shared tenant-scoped D1 database as I originally wrote — see #7173. The conclusion (close, no sharding strategy needed) still holds either way, since per-tenant-isolated databases need no sharding regardless of which specific backend each container uses.