now that DOs are on sqlite 3.47, any reason why the jsonb functions (https://sqlite.org/json1.html)

now that DOs are on sqlite 3.47, any reason why the jsonb functions (https://sqlite.org/json1.html) have not been added to the allowed list? (https://github.com/cloudflare/workerd/blob/e08e889ea309aae905952980277f0a7372e15ae0/src/workerd/util/sqlite.c%2B%2B#L379)

getting a runtime error at the moment on a brand new sqlite DO:

Error: not authorized to use function: jsonb at offset 60: SQLITE_ERROR

Error: not authorized to use function: jsonb at offset 60: SQLITE_ERROR

TTom Sherman In the "one database per user" architecture is it best to use D1 or durable obje...

gruntlord6•8/13/25, 6:31 PM

It’s not impossible with d1 buts it’s also certainly not easy since workers don’t support dynamic bindings. Durable Objects only need a binding for the class you are using and you can use a different name space for each user to get a new object instance that’s unique

gruntlord6•8/13/25, 6:31 PM

If workers supported dynamic bindings it would be a bit of a different discussion

Ggruntlord6 It’s not impossible with d1 buts it’s also certainly not easy since workers don’...

Larry•8/13/25, 7:53 PM

This is essentially correct, but I wanted to give a bit of a terminology correction because it is very confusing. It's not exactly clear from reading the Durable Objects Glossary, so I'll use code to explain.

In this example:

you might think that MY_DURABLE_OBJECT is the namespace. I did until very recently, but that's just the binding to the DO class for this Worker. It can have a different binding name from another Worker.

The actual DO namespace is a resource that encompasses all of the DO instances that are bound to this DO class across all Worker bindings. When fully qualified (like in the dashboard), it's preceded by this Worker's name as defined by the top-level key in wrangler config in the owning DO. In other Workers, you specify the owning DO via the key. So, in the example above.

In older documentation, it was always shown ALL_CAPS. I think it's because it shows up in your as which matches the case for other env things like environment variables.

Still with me? Nowadays, it's common to see this in Cloudflare's own libraries and docs:

That's how I prefer to do it now also because it means I won't have to remember the case and I almost always have a 1:1 between class and namespace... unless of course you are using the routing handler that ships with the agents SDK (which is a legacy from the PartyServer origins of the agents SDK), where it is converted to snake-case, so "my-durable-object". Crazy, huh?!?!

Hang with me, because here's where it gets really fun (read "confusing"). When you are accessing a DO from a Worker like this:

"do-for-acme-co" is the... drum roll please... "Name" in . I'll never forget the moment 3+ years ago when @HardlyWorkin' (I think) found the bug in my code where I got this mixed up and stopped me from jumping off the ledge.

Ggruntlord6 It’s not impossible with d1 buts it’s also certainly not easy since workers don’...

Larry•8/13/25, 7:58 PM

So, you wouldn't use "a different namespace for each user". You would use a different "name" in the call

gruntlord6•8/13/25, 9:48 PM

Yes that was incorrectly stayed on my part

1984 Ford Laser•8/14/25, 6:34 AM

Wanna get some thoughts on how to handle this use case:
I need to synchronise a a countup timer between two types of clients. Currently, the clients poll an API which gives a datetime to signify the timer start, when field is changed then timer ticks up second by second on each client independently. Over a 30 min period these two diff client types drift up to a couple mins from each other, due to differences in how each works. If both clients were to connected to a hibernated DO WS, what would be the best way to keep a timer synced? Call an alarm() every ~1000ms and send the current time value, or continue to let each client handle on its own? Can I rely on a self-setting alarm to be 'roughly' accurate over a particular time period (for my use case, within 10 seconds drift over 30 mins would be acceptable)

kyle•8/14/25, 5:25 PM

Is there any way to roll out a Durable Object that does not reset running instances? Even with gradual deployments, eventually the Worker is reset because it's code is updated.

My ideal UX is I deploy, in-progress DOs finish, and then on the next alarm or next request, the new version comes in.

Kkyle Is there any way to roll out a Durable Object that does not reset running instan...

cloudkite•8/14/25, 7:43 PM

theres no option for that behaviour see https://community.cloudflare.com/t/durable-objects-state-during-lifecycle-events/319932/5

I would love if it was possible to have that behaviour as a flag or similar. But possibly theres tradeoffs or architectural reasons for why cloudflare hasn't implemented this

Ccloudkite theres no option for that behaviour see https://community.cloudflare.com/t/durab...

kyle•8/14/25, 7:54 PM

Do you know what throws the type error? Is it writing to storage? Or is it just any DO that has touched storage will exit with such?

Kkyle Do you know what throws the type error? Is it writing to storage? Or is it just ...

cloudkite•8/14/25, 8:03 PM

From the linked post: "but any old ongoing requests are able to send a response so long as they don’t throw an error first (e.g. by trying to use the storage API)."

Kkyle Is there any way to roll out a Durable Object that does not reset running instan...

Larry•8/14/25, 9:03 PM

What if a meteor hits a data center?

It adds complexity, but the general recommendation is to design your system (DOs and things that call them) such that it would be OK if the DO were to go away with no notice because there are many reasons why that might happen besides the roll out scenario you describe.

LLarry What if a meteor hits a data center? It adds complexity, but the general recomm...

kyle•8/14/25, 9:15 PM

I agree - it's not mission-critical if it goes away, but it's obviously a bad user-experience.

Kkyle I agree - it's not mission-critical if it goes away, but it's obviously a bad us...

gruntlord6•8/14/25, 9:18 PM

yes but something like a websocket reconnect or retrying the http request basically makes it some added latency. I know there are plans to make it so they do not reset when updated but they haven't said anything close to a timeline on that

LLarry What if a meteor hits a data center? It adds complexity, but the general recomm...

cloudkite•8/14/25, 11:11 PM

Agree doesn’t negate need to design in resilience via retries to your DO calls but reducing frequency that they can/will throw I think is still a worthy goal

Ggruntlord6 yes but something like a websocket reconnect or retrying the http request basica...

Larry•8/14/25, 11:25 PM

I hadn't heard that. That's good news if true.

Kkyle I agree - it's not mission-critical if it goes away, but it's obviously a bad us...

Larry•8/14/25, 11:41 PM

Other than potentially a bit of added latency, you can design it so the user doesn't experience any difference... although that is more complexity.

LLarry I hadn't heard that. That's good news if true.

gruntlord6•8/15/25, 12:06 AM

It was a thread here where someone from the team was tagged by another employee asking for it and they replied it's in the works but not possible atm and no timeline

wildbill•8/15/25, 3:24 PM

So i got question what does this mean I was on this website few hours ago and then this popped up

wildbill•8/15/25, 3:24 PM

Wwildbill So i got question what does this mean I was on this website few hours ago and th...

Isaac McFadyen•8/15/25, 3:26 PM

It means the developer has added a requirement to log in to access that page.

wildbill•8/15/25, 3:27 PM

Could it because the website not fully out yet and its in pre launch?

Wwildbill Could it because the website not fully out yet and its in pre launch?

Isaac McFadyen•8/15/25, 3:28 PM

Yes that's possible.

wildbill•8/15/25, 3:30 PM

OK thank you. The website is playshuffle.us

see translation•8/18/25, 6:05 PM

The DO docs describing their lifecycle is self contradictory in multiple places. Which of these is true?

see translation•8/18/25, 6:07 PM

I want to gaurantee my DO will survive for at least 30 seconds after the last request. Should I use for this?

Ssee translation I want to gaurantee my DO will survive for at least 30 seconds after the last re...

geg•8/18/25, 6:33 PM

The 10 seconds is when the DO doesn't do any work, 70 seconds when it is doing work

see translation•8/18/25, 6:40 PM

I sometimes want to ensure the DO stays alive for at least 30 seconds (whether it has work or not), should I just use / . I'm using Rust

Ssee translation I sometimes want to ensure the DO stays alive for at least 30 seconds (whether i...

geg•8/18/25, 6:43 PM

you don't need waitUntil, when you do anything such as setInterval() it will stay active for up to 70 seconds, but you will pay for the full 70 seconds so not really worth doing that in any case

see translation•8/18/25, 6:45 PM

I don't (think?) I have setInterval in rust land. I was going to try to use waitUntil for that purpose. Perhaps a better thing to do would be to shell out to JS.

Ssee translation I don't (think?) I have setInterval in rust land. I was going to try to use wait...

geg•8/18/25, 6:47 PM

It's just an example, and waitUntil doesn't do anything, and it's most likely cheaper to just put state in storage rather than keep the DO active

see translation•8/18/25, 6:49 PM

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 translation•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 translation•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 translation•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 translation•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 translation•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 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 translation•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 translation•8/18/25, 7:21 PM

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

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

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

see translation•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.