Definitely use DOs not D1 if it's per

Definitely use DOs not D1 if it's per user. You will struggle with binding otherwise. The nice thing about going the DO route also is that you can encapsulate everything that your client code needs into methods in the DO. For now, they can use the SQLite 10GB DB inside of the DO. You can monitor and see how fast they are growing. If one of your users reaches 5GB in a year, then you'll have a year to migrate the storage part somewhere else, or figure out how to shard. I think you'll be surprised how far 10GB goes. One bad thing about 5GG+ dbs in DOs though is that cold starts can be 1+ seconds if Cloudflare has to move the db file to the machine where the DO runs.

James•11/23/25, 3:53 PM

im curious about what you mean by cold starts in this context, i have heard people having issues running queries with large 5GB+ dbs in DO, but thats not necessarily the same as having a large db and performing tightly scoped indexed queries on it

LarryOP•11/23/25, 4:05 PM

Each DO instance has access to an SQLite DB. That DB is in a file. Whenever DOs are not in use the DO will either hibernate then fully evict or simply evict from memory after some period of time where it hasn't had new requests. I'm guessing that if it hibernates, it keeps its DB file nearby but I don't know. Regardless the local file is released after some time. Then, when a new request comes in, it may have to fetch that file from somewhere else and bring it to the machine that is running the DO. At 5GB+, that takes 1 second +.

Here's the lifecycle diagram for a DO, although it only talks about hibernation and eviction, not where the DB file is and when. That's local lore and isn't documented anywhere other than in chats on here as far as I know.

In a traditional DB, the "files" holding the data are not moved around like that. Rather the network traffic is brought to where the file is.

James•11/23/25, 4:09 PM

I would doubt that's the case, my impression is the db data is tightly coupled w the DO physical location, and moving it around is more of an edge case for DO transport itself, like a DO machine fails and CF infra is forced to start the DO elsewhere and bring with it a backup / last commited state of the DB.

James•11/23/25, 4:10 PM

All the complaints I see about people with large DO DB latency issues look related to index mgmt.

LarryOP•11/23/25, 4:16 PM

durable-objects

LarryOP•11/23/25, 4:17 PM

That was the closest confirmation I could find on the DO channel's recent posts, but I've read it several times. Maybe Lambros is the one who has said it every time I've read it, but he would know.

LarryOP•11/23/25, 4:21 PM

I could be misunderstanding. Maybe the slow cold starts aren't from moving files so much as maybe something like loading indexes into memory. But I'm fairly confident that Lambros, who would know, believes that large database sizes equate to slow cold starts.

James•11/23/25, 4:22 PM

from what i know, the main concern w cold starts its strictly not having a warm worker or DO, and loading and compiling your own js bundle from zero. the data access DO-sqlite should always be hyper fast latency-wise. large DBs bring latency up through higher CPU, I/O isolated within the sqlite context and memory utilization on the DO itself.

JJames from what i know, the main concern w cold starts its strictly not having a warm ...

LarryOP•11/23/25, 4:23 PM

Could be.

LarryOP•11/23/25, 4:23 PM

But Lambros explicitly mentions cold starts

James•11/23/25, 4:24 PM

all this being said, I plan on maintaining a max of toughly 1gb per user on my DOs with continuous truncation of less important records

James•11/23/25, 4:24 PM

the fact that we're limited to 128mb per DO is enough to stray away from large datasets

LarryOP•11/23/25, 4:26 PM

I have been pleasantly surprised that 128mb has not been a limitation in my experience. I don't keep anything in memory though. I read it from storage right before I need it every time and let it go quickly. YMMV.

JJames I would doubt that's the case, my impression is the db data is tightly coupled w...

lambrospetrou•11/24/25, 12:27 AM

I would doubt that's the case, my impression is the db data is tightly coupled w the DO physical location,

The cold starts I usually refer to for large multi-GB DBs are indeed as Larry says for the time to download from cold storage the SQLite data.

As James said though, too, we do try to reuse previous files as much as possible. However, it's inevitable that DOs will move machines throughout time, and in those cases we need to fetch the full dataset again.

I cannot provide an estimate of "how often a cold start happens", since it depends on many reasons, but it happens.

As James eluded though, the main issue I also see with multi-GB DOs is query efficiency and trying not to scan entire tables ever to avoid hitting the cpu/memory limits.

makima•11/24/25, 5:10 AM

thanks all, very useful information , im going to test the per user db with do and see how goes

Definitely use DOs not D1 if it's per

Similar Threads

Similar Threads

Similar Threads