The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Before moving D1 data into Durable Objects, identify which queries stay within one room or entity and which need records owned by several. Each Durable Object has private attached storage, so a query in one object cannot simply join data stored in other objects. The inventory below helps you find those boundaries before they become an application redesign.
What to record for every query
Create one row for each query or query family, including operations issued indirectly by an ORM, scheduled task, or background job. Record enough detail to understand both what the query does and which part of the application depends on it.
As an Amazon Associate I earn from qualifying purchases.
- Feature and caller: the application feature, calling Worker route, and any scheduled or background process.
- Query shape: SQL or ORM operation, tables touched, filters, joins, sorting, and aggregation.
- Workload: whether it reads or writes, expected rows returned or changed, frequency, burst behavior, and required transaction boundaries.
- Database details: relevant indexes and the result size the application actually needs.
- Ownership: the room, user, document, match, or other entity that could own the data in a Durable Object.
- Boundary: whether the operation touches one proposed owner or combines data from multiple owners.
This is an engineering checklist, not an official Cloudflare migration checklist. Its purpose is to expose query patterns that may be hidden by the current relational schema.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Classify queries by ownership and purpose
Object-local reads and writes
These operate on data owned by one room or entity. They are candidates for storage attached to that entity’s Durable Object when the object is also a natural authority for the feature. A match’s current state or a room’s messages may fit this pattern, depending on the application’s requirements.
Cross-object queries
These combine data owned by multiple rooms or entities. Examples include a screen that lists activity across a user’s rooms or a report that joins records from several documents. Mark each one explicitly: Durable Objects do not provide a shared relational database across instances. Choose an explicit read design, such as application-level fan-out, a maintained summary, a separate shared store, or keeping the query in D1.
Relational and reporting queries
Queries that depend on flexible joins, broad filtering, or analytics across many entities may be a poor fit for scattering the source records among object-private stores. Compare the cost and complexity of rebuilding those read paths with keeping that workload in D1 or another suitable store.
Coordination state
Durable Objects are intended for coordination-centered workloads, including chat, collaborative editing, multiplayer interactions, and live notifications. Consider them where multiple clients need one authoritative state boundary for a room or similar entity—not as a default destination for every table.
Free tools Windows power users keep installed
One-click scans. No signup required.
Why the boundary changes the design
D1 is Cloudflare’s SQL database. Cloudflare describes it as including schema management, data import and export, and query insights. Durable Objects combine uniquely addressed stateful compute with storage: a front-end Worker routes requests to a particular object, whose attached storage is private to that instance. The object storage API offers strongly consistent, transactional storage; SQLite-backed Durable Objects also expose SQL APIs. See Cloudflare’s D1 and Durable Objects comparison and documentation on accessing Durable Objects storage and SQLite-backed Durable Object storage.
This makes the ownership decision architectural. A room-local write can be handled by the room’s object, but a cross-room feature needs a defined way to find and combine the relevant data. Decide how that view is generated and kept current before moving its source records; freshness, consistency, latency, and operational complexity may differ among the available designs.
Cloudflare recommends SQLite-backed storage for new Durable Object namespaces. Its SQL API applies to SQLite-backed classes; it is not a cross-object SQL interface. Cloudflare’s Durable Objects overview describes coordination use cases, while its application data storage guidance provides broader storage context.
Keep D1 constraints in the inventory
Do not assume a migration is worthwhile just because a query is slow or a table is growing. Cloudflare’s D1 FAQ gives rough, non-guaranteed guidance: an indexed read such as looking up a name by ID may take less than a millisecond of SQL duration; writes such as INSERT or UPDATE may take several milliseconds, depending on the rows written. These are Cloudflare’s approximate figures, not end-to-end application latency guarantees. The same FAQ says a Worker invocation can open up to six simultaneous D1 connections. See the D1 FAQ.
For broad changes, Cloudflare advises batching large UPDATE or DELETE work. Its FAQ gives roughly 1,000 rows at a time as an example batch size and warns that a single query affecting hundreds of thousands of rows or hundreds of megabytes may exceed limits. Treat the example as guidance, not a universal batch-size prescription. Capture index coverage, concurrency, and result size alongside query text; check current limits and pricing for your account and workload before making a decision. Cloudflare says SQL query pricing and limits are intended to be identical between D1 and SQLite in Durable Objects, but their APIs and management responsibilities differ.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A practical migration sequence
- Capture the current baseline. Record the schema and query inventory, including ORM-generated operations, routes, jobs, indexes, and transactions. Cloudflare documents D1 SQL migrations at D1 migrations.
- Assign proposed owners. Group records by the room or entity that could own a Durable Object, then mark every query that crosses those boundaries.
- Choose a read path for each boundary-crossing query. Decide whether the feature can change its read path, use a maintained summary or separate store, or remain in D1. Document the consequences for freshness, consistency, latency, and operational work.
- Prototype a representative object. Test the query and write patterns for one realistic entity. Confirm that Worker routing reaches the intended object and that results preserve the semantics the application requires.
- Plan data movement and recovery separately. Define export, loading, verification, and rollback steps. Batch large data changes in line with D1 guidance. Cloudflare documents D1 SQL migrations and Durable Object storage separately; the cited documentation does not establish a turnkey D1-to-Durable-Objects migration command.
How to make the keep-or-move decision
| Decision factor | What to look for | Implication |
|---|---|---|
| Query scope | One owner versus joins, reports, or reads across owners | Object-local access is easier to align with private object storage; cross-owner access needs an explicit design. |
| Data ownership | Whether a room or entity naturally owns the records and has one authority | A clear owner can support an object boundary; shared records may need another home or representation. |
| Coordination | Whether clients need coordinated state for one entity or a broad relational view | Coordination-heavy behavior is a stronger Durable Object use case than general-purpose reporting. |
| Application and operations | Worker routing, import/export, schema management, query insights, and tooling the team must provide | D1 offers more database-management features; Durable Objects give application code more control and responsibility. |
| Limits and cost | Current account plan, workload, platform limits, and billing | Verify current details for both choices; do not infer universal speed or cost advantages from the storage model. |
The useful outcome is not necessarily a complete move. Keeping relational or cross-room workloads in D1 while using Durable Objects for the coordination state that benefits from a clear owner can be a valid design. Make that call query by query, based on the access patterns the application must preserve.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
