The problem is that I'm using Worker KV (because DO storage value size is too small) which isn't glo

The problem is that I'm using Worker KV (because DO storage value size is too small) which isn't globally consistent for ~30 seconds. So if the DO dies in this time, and restarts, it may fetch an outdated value.

see translationOP•8/18/25, 6:50 PM

So I want the DO to stay alive for at least 30seconds to ensure Worker KV's state has propagated.

Ssee translation The problem is that I'm using Worker KV (because DO storage value size is too sm...

lambrospetrou•8/18/25, 6:50 PM

If the reason you want the DO to stay alive is correctness, I suggest changing your algorithm somehow. The DO can die at any point due to unexpected issues for example.
What do you want to achieve exactly? Also, KV has up to 60s propagation, not 30s.

see translationOP•8/18/25, 6:53 PM

I'm storing a document in Worker KV which the DO manages. I switched to using worker KV because r2 cold reads took around 200ms on average, worker KV was faster.

Llambrospetrou If the reason you want the DO to stay alive is correctness, I suggest changing y...

see translationOP•8/18/25, 6:57 PM

I have been thinking about that, it would be nice to know how likely that is to happen. If it is rare enough I think the errors/inconsistencies could be manageable

Ssee translation I have been thinking about that, it would be nice to know how likely that is to ...

lambrospetrou•8/18/25, 6:58 PM

I still don't know what you are trying to solve by keeping it alive. So, the DO writes a new value to KV. What next? Why do you need the DO alive?

see translationOP•8/18/25, 6:59 PM

The DO is the source of truth for the document. When it boots up it loads the last value from Worker KV. But if it dies and reboots within 30 seconds of the last write to worker KV it might get an older version of the document.

see translationOP•8/18/25, 7:00 PM

clients connect to the DO and update the document (using the loro CDRT library)

Ssee translation The DO is the source of truth for the document. When it boots up it loads the la...

lambrospetrou•8/18/25, 7:03 PM

KV provides a read your own writes guarantee within the same colo, but in this case I wouldn't depend on that in case the DO boots in a different colo.
So, my suggestion if correctness matters is to store the KV value in the DO itself first, then in the KV so that DO is the source of truth. You can chunk it to fit the DO storage. Are you using SQLite DOs?

Or, at least you should keep an

update_at

update_at

timestamp in the item stored in KV, and when the DO writes a new value to KV also write into its own storage that timestamp, so when you boot you will know if the value from KV is the latest or not. Unfortunately, though, even if you detect it's not the latest you won't be able to get the latest from KV maybe up to 60s.
So, again, if the DO is the source of truth, its own storage should be used and makes things much simpler to reason about.

see translationOP•8/18/25, 7:21 PM

I'm using DO KV store. Do you think SQLite would be better? I have some semi-relational data.

I am currently storing the document "updates" in the DO KV. The updates can be applied idempotently, so I could do a thing where I apply them to the document fetched from the Worker KV to ensure it's the latest version

see translationOP•8/18/25, 7:21 PM

I do have a "updated_at" in the Worker KV metadata.

see translationOP•8/18/25, 7:23 PM

My first impression was that storing binary blobs in the SQLite would be... not great?

see translationOP•8/18/25, 7:27 PM

@lambrospetrou My documents can be up to ~3MB but most are around a couple hundred KB. Do you think this would work better in SQLite? Or faster?

Ssee translation @lambrospetrou My documents can be up to ~3MB but most are around a couple hundr...

lambrospetrou•8/18/25, 7:28 PM

In SQLite DOs each row can hold close to 2MB. In a personal project I just chunk large items into multiple rows of 1.5MB each. 3MB should be totally OK to store in SQLite DOs.

see translationOP•8/18/25, 7:32 PM

Interesting, what sort of schema are you using? Do you write over existing blobs when they change? Or do you just add a new row with the changed version?

see translationOP•8/18/25, 7:33 PM

@lambrospetrou I'm curious how a row in the schema indicates it a partial blob, or like the Nth blob.

Ssee translation Interesting, what sort of schema are you using? Do you write over existing blobs...

Larry•8/18/25, 7:40 PM

Note, even with SQLite-backed DOs, you can still use the DO KV API. They just use a hidden table. That said, with chunking, I would lean towards a compound primary key

(id, chunk)

(id, chunk)

if you went with a replacement model. You don't need to use all of the segments in order for it to take advantage of the automatic primary key index. So,

...WHERE id=<some-id>

...WHERE id=<some-id>

will return all of the chunks whether there is one or many.

Ssee translation @lambrospetrou I'm curious how a row in the schema indicates it a partial blo...

lambrospetrou•8/18/25, 7:46 PM

See https://github.com/lambrospetrou/tiddlyflare/blob/2f6cd98eab2d77f8319cca21922dea3a8ca41d9a/src/durable-objects.ts#L232 from one of my projects.
This is the read part that makes sure I only read complete versions with all their chunks written: https://github.com/lambrospetrou/tiddlyflare/blob/2f6cd98eab2d77f8319cca21922dea3a8ca41d9a/src/durable-objects.ts#L426

GitHub

tiddlyflare/src/durable-objects.ts at 2f6cd98eab2d77f8319cca21922de...

Hosting platform for TIddlyWikis. Contribute to lambrospetrou/tiddlyflare development by creating an account on GitHub.

LLarry Note, even with SQLite-backed DOs, you can still use the DO KV API. They just us...

Jehu•8/18/25, 9:28 PM

Is the pricing for SQLite-do k/v api row-based? Or is it the same as non-SQLite-do k/v?

JJehu Is the pricing for SQLite-do k/v api row-based? Or is it the same as non-SQLite-...

lambrospetrou•8/18/25, 10:30 PM

Separate, and yes it's row based and storage used based: https://developers.cloudflare.com/durable-objects/platform/pricing/#storage-billing

Burrito•8/19/25, 1:20 PM

DO SQLite has a minimum of ~4 KB if you store anything at all, are those 4 KB charged?

BBurrito DO SQLite has a minimum of ~4 KB if you store anything at all, are those 4 KB ch...

gruntlord6•8/19/25, 1:31 PM

anything past the free limit is charged IIRC, so you won't be charged for 4kb but you would be charged for every 1gb over the free tier

Burrito•8/19/25, 1:33 PM

Eh I meant that, if I have for example 1 million SQLite backed DOs each storing 1 byte of my own data, would the total come out to be 1 byte x 1 million, or ~4 KB x 1 million?

cloudkite•8/19/25, 7:29 PM

Question for DO experts around how implicit transations work. Asumming I have understood this correctly the following would be two transations due to IO inbetween:

cloudkite•8/19/25, 7:30 PM

cloudkite•8/19/25, 7:30 PM

Does this mean if I use waitUntil then I would have one transaction:

cloudkite•8/19/25, 7:30 PM

cloudkite•8/19/25, 7:31 PM

Unsure if in second scenario it would be one or two transactions? Is the implicit transaction boundary at await or by a IO being triggered/started?

Ccloudkite Question for DO experts around how implicit transations work. Asumming I have un...

lambrospetrou•8/19/25, 7:47 PM

I posted about implicit transactions a while back: durable-objects

In general, please just be explicit and put explicit transactions. Do yourself a favor, and also your colleagues.
There is absolutely zero reason to play guess games on what triggers one or two implicit transactions and then end up with an incorrect code because someone added a line in the middle 6 months down the future.

I know our docs suggest implicit transactions, and I am hoping to change them, but just do the easy/simple thing.

Llambrospetrou I posted about implicit transactions a while back: https://discord.com/channels/...

cloudkite•8/19/25, 7:51 PM

Thanks makes sense!

BBurrito Eh I meant that, if I have for example 1 million SQLite backed DOs each storing ...

1984 Ford Laser•8/19/25, 10:42 PM

4-12KB per object
https://developers.cloudflare.com/durable-objects/platform/pricing/#does-an-empty-table--sqlite-database-contribute-to-my-storage

Burrito•8/19/25, 10:47 PM

I see, didn't see that part, and for some reasons I had the impression of 4 KB for an empty database.

Burrito•8/19/25, 10:48 PM

I guess for some use cases KV backed DO would still be better then.

Larry•8/19/25, 11:58 PM

I'm not really recommending this--more just thinking out loud, but you could call

deleteAll()

deleteAll()

when they are emptied, then recreate them lazily if they don't exists when you go to put your first thing in the database. This is a lot of complexity but if you have 1M DOs and most of them are empty, it might be worth it.

Burrito•8/20/25, 12:00 AM

It's not about empty DOs, but just having lots of DOs and each store a small amount of data, that the 12 KB overhead is significant.

gruntlord6•8/20/25, 1:25 AM

Yea but at that point I feel like there’s a lot of overhead from spreading that thin

plgingras88•8/20/25, 1:41 AM

Indeed it may feels you over-chunk your DOs.

Larry•8/20/25, 1:43 AM

We have no idea what Burrito's system does so it's hard to draw that conclusion. That said, my first architecture on DOs was too fine grained and I had that cost of coordination problem

Burrito•8/20/25, 1:44 AM

Scaling horizontally is a big point of using DOs.

Burrito•8/20/25, 1:46 AM

In my case I'm using a DO for each user, I have users all over the world, each user's DO operates on itself, and most users don't store much data. It's imo a perfect use case compared to a monolith, and the 12 KB overhead of SQLite storage is simply too much. Good thing the project was made back then KV storage was the only option and it turned out to be the right choice.

Larry•8/20/25, 1:54 AM

Yeah, that sounds like the ideal architecture for your situation. Too bad it sounds like the old KV-only backend is targeted for deprecation at some point. I hope you can convince Cloudflare to essentially subtract the tare weight of a DO before calculating it's size. It only seems right to me.

Tare weight

Tare weight , sometimes called unladen weight or empty weight, is the weight of an empty vehicle or container.
By subtracting tare weight from gross weight (laden weight), one can determine the weight of the goods carried or contained (the net weight).

Burrito•8/20/25, 1:58 AM

Yeah 12 KB empty database size with 1 million DOs would result in 12 GB of storage being billed. It's not great, and especially since DO is perfect for these kinds of use cases.

Burrito•8/20/25, 2:00 AM

Though I'm under the impression that KV storage isn't being deprecated, just that Cloudflare is recommending people to default to SQLite storage. Is that not the case and KV storage is actually being deprecated? That would be very problematic.

plgingras88•8/20/25, 2:02 AM

Have you considered using r2 instead ? Store a json object for each user

Burrito•8/20/25, 2:05 AM

R2 is even worse. Not only is the pricing more expensive, R2 buckets also only exist in few locations, and you also cannot execute logic near the object so you have to pay the round trip cost twice if you do read then write.

Burrito•8/20/25, 2:06 AM

IIRC R2 is built on top of DO, so that's not surprising.

BBurrito Though I'm under the impression that KV storage isn't being deprecated, just tha...

Chaika•8/20/25, 2:07 AM

They talked about migrating automatically a while ago
https://blog.cloudflare.com/sqlite-in-durable-objects/
"We plan to begin migrating existing DOs to the new storage backend in 2025."

Chaika•8/20/25, 2:09 AM

Since Sqlite DOs support the same KV interface it would in theory just work, who knows what they'd do with billing though, and CF doesn't do well with ETAs lol

Burrito•8/20/25, 2:10 AM

Yeah the API doesn't matter much to me, it's just changing some code (although SQLite API is nicer to use than KV), it's the storage that matters.

Burrito•8/20/25, 2:11 AM

Is there a good way to raise awareness for the issue? It's surprising to me that this is being overlooked, DO is almost tailor made for these kinds of use cases.

BBurrito R2 is even worse. Not only is the pricing more expensive, R2 buckets also only e...

plgingras88•8/20/25, 2:11 AM

Well, I haven't compared toes-to-toes all aspects and it surely changes, depending on your read/write frequency and other factors. But R2 egress is free and it's storage is $0.015 / GB-month, compared to DO $0.20/ GB-month. Plus, R2 has the (beta) feature to switch to Infrequent Access storage for $0.01 / GB-month.