Exactly what @Larry said. I need to update the README of my library to explain this since many folks

Exactly what @Larry said. I need to update the README of my library to explain this since many folks ask about it at this point. It seemed a bit obvious to me, but I was wrong assuming that.

Llambrospetrou Exactly what @Larry said. I need to update the README of my library to explain t...

jcheese•5/1/25, 11:23 AM

The internals of the DO and when constructor gets called and stuff isnt so obvious

jcheese•5/1/25, 11:24 AM

Thanks though, amazing library

VVy Following https://blog.cloudflare.com/d1-read-replication-beta/, CF team is star...

DaniFoldi•5/1/25, 11:24 AM

I'm still hoping one day we'll have DOs in all colos, even if storageless - the use case is for websocket handling and chat rooms where persistence is external anyways

DDaniFoldi I'm still hoping one day we'll have DOs in all colos, even if storageless - the ...

Zack•5/1/25, 11:29 AM

Isn't storageless DO just a worker?

ZZack Isn't storageless DO just a worker? 🤔

DaniFoldi•5/1/25, 11:30 AM

you can't use hibernation, connect multiple websockets to the same worker, so not quite

Zack•5/1/25, 11:30 AM

Ah I see

DaniFoldi•5/1/25, 11:30 AM

but I see where you're coming from, for a simple proxy, or maybe a filtering/logging service, yeah regular workers are just fine (even better for some things since no wall time charges)

ZZack Isn't storageless DO just a worker? 🤔

lambrospetrouOP•5/1/25, 11:34 AM

The big benefit of DOs over workers even without storage is coordination due to the global uniqueness of the DO ID.

Tobias•5/1/25, 6:44 PM

We just had a customer having an outage on an important realtime-flow because a DO was hanging for >1h - no requests timed out, they were hanging in pending state.

I'm a bit out of ideas here - since there are no errors, or no indicators on why this suddenly happened.

A re-deploy fixed this, and all connections were reset.

Tobias•5/1/25, 6:45 PM

(This wall time is from an alarm in a different DO that uses RPC to connect here)

Tobias•5/1/25, 6:46 PM

In the morning we had requests erroring with an overload error - self-recovered just fine after the load was gone. But this time, we're a bit clueless - especially since there was no self recovery :/

Tobias•5/1/25, 6:47 PM

The DB in the DO is still relatively small for DB standards, with just 50k records. Nothing that should hit the limit.

Tobias•5/1/25, 6:57 PM

@Sunil Pai - this was a partyserver DO with hibernation, not sure if you have seen this one before

Tobias•5/1/25, 7:15 PM

just happened again

Tobias•5/1/25, 7:24 PM

Yes, the requests are simply not connecting from either outside w/ Websockets or inside with RPC

Tim Lonsdale•5/2/25, 4:30 PM

Hey chaps, we've just started playing around with Sqlite Durable objects. We created a really simple alarm DO that wakes itself up every minute. The actual stored data is de minimis. Its a single column in a single row in a single table of ~100 bytes max. We've had this running for not very long - but our billable duration has already hit 1.6GB-s. I feel like that can't be right - do DOs have some fixed "base" storage associated with them?

Tobias•5/2/25, 4:52 PM

This is not storage but rather a RAM-like billing

Tobias•5/2/25, 4:53 PM

1,6GB-secs mean your DO was active for about 12 secs

TTim Lonsdale Hey chaps, we've just started playing around with Sqlite Durable objects. We cre...

lambrospetrouOP•5/2/25, 4:56 PM

It's indeed confusing to calculate it, but 1.6GB-sec means it's 12.5 seconds of 128MB (the DO memory you are charged). As Tobias said.

Tim Lonsdale•5/2/25, 4:57 PM

Ah but I assumed the DO was loaded into memory and thus the 128MB was the “size” of the DO

TTim Lonsdale Ah but I assumed the DO was loaded into memory and thus the 128MB was the “size”...

lambrospetrouOP•5/2/25, 5:00 PM

Durable Objects are code like Workers, and they have durable storage you can use up to 10GB. They don't load all that storage in memory. Your DO has 128MB to use for its normal code operations, and tha'ts what you are charged for duration. The durable storage itself is charged separately.
Read https://developers.cloudflare.com/durable-objects/platform/pricing/ if you haven't.

Tim Lonsdale•5/2/25, 5:03 PM

Ah thanks for the clarification

baher•5/3/25, 2:39 PM

anyone knows how long it takes to get into the realtimeSDK beta? I applied on the 17th of april and did not get in yet

SuperHelpflare•5/3/25, 6:34 PM

Please do not post your question in multiple channels/post it multiple times per the rules at #

welcome-and-rules. It creates confusion for people trying to help you and doesn't get your issue or question solved any faster.

formatc2013•5/5/25, 6:40 AM

Hey everyone!

I have a C++ application, that creates its own sqlite database for its internals. I want to use it in a Cloudflare Durable Object. I recompiled to Webassembly, created Emscripten bindings, so now I can trigger the creation of the aforementioned database from JS, in a Durable Object class.
Question:

is this setup taking advantage of the Durable Object setup ?
or in other words, do I have to feed my query strings to
this.sql.exec(...)
or is the db created by my C++/WASM code is just as fast?

The answer seems to me that I have to use this.sql.exec(...) from the Durable Object API, but I'd like to double check before I get to coding!
https://developers.cloudflare.com/durable-objects/api/storage-api/#sql-api

Thanks

Cloudflare Docs

Durable Object Storage

The Durable Object Storage API allows Durable Objects to access transactional and strongly consistent storage. A Durable Object's attached storage is private to its unique instance and cannot be accessed by other objects.

Fformatc2013 Hey everyone! I have a C++ application, that creates its own sqlite database fo...

lambrospetrouOP•5/5/25, 8:11 AM

Your WASM database will definitely be slower. And unless you use the DO storage I don't see how your changes will be durably persisted if you only do them inside WASM.

veeque•5/5/25, 8:28 AM

when adding / keys to my queries what's the upper practical limit i should use?

Vveeque when adding `limit`/`offset` keys to my queries what's the upper practical limit...

lambrospetrouOP•5/5/25, 8:32 AM

Depends on your queries, we have folks doing hundreds of thousands of rows read per second, and we have seen a few low millions too. It depends how many of these queries you have in parallel since your DO will be blocked for that amount of time per request.
A few low/single-digit thousands should be a good ballpark to start with to still stay within a few milliseconds.

Original message was deleted

veeque•5/5/25, 9:21 AM

yes i was planning on doing that but i thought saying limit/offset would get my point across better

JJan Wilmake this is cool! i wonder how you would interface with actual storage though, is th...

formatc2013•5/5/25, 12:25 PM

i have singleton pubsub in cpp

I use emscripten::val to call js from c++

using QueryCallback = std::function<void(const std::string &)>;

c++ publishes and I in my bindings I subscribe with a function that calls into JS, and passes query string

val jsFunc = val::global("printName");
QueryCallback cb = [&jsFunc](const std::string &query) { jsFunc(query); };
pubsub_singleton.addListener(cb);

formatc2013•5/5/25, 12:39 PM

i'd be a lot nicer with a C++ API

ac•5/5/25, 4:15 PM

Why is there no ability to list the DO instances (or at least the number of them) on the web dashboard? I get that it is accessible via the REST API, but it seems like something that should be on the dashboard... (unless I am missing something)

Fernando Barroso•5/5/25, 9:39 PM

Has anyone built a sharding library for DOs to grow dynamically once req/s or storage limits are hit? I remember seeing something like that at some point in this chat

Avi•5/5/25, 9:43 PM

how much time after the last user disconnects will a DO spin down?

Avi•5/5/25, 9:43 PM

i need to know because we have some long-running async tasks to run

Avi•5/5/25, 9:44 PM

wondering if we need e.g. in a DO

AAvi wondering if we need e.g. `waitUntil()` in a DO

Hard@Work•5/5/25, 9:44 PM

IIRC doesn't give you more time in a DO

Hard@Work•5/5/25, 9:45 PM

The request context for a Durable Objects extends at least 60 seconds after the last client disconnects. So waitUntil is not necessary. It remains part of the DurableObjectState interface to remain compatible with Workers Runtime APIs.

FFernando Barroso Has anyone built a sharding library for DOs to grow dynamically once req/s or st...

lambrospetrouOP•5/5/25, 9:46 PM

I have that in progress for my own library (), but not ready yet for any external use. I haven't seen any other library providing that though already.

HHard@Work IIRC `waitUntil` doesn't give you more time in a DO

Avi•5/5/25, 9:48 PM

oh interesting. that makes me nervous though... i have some DO code that essentially works like a regular HTTP router and i'm using waitUntil for good measure

Avi•5/5/25, 9:48 PM

why even expose that if it's truly a no-op?

AAvi why even expose that if it's truly a no-op? 🤔

Hard@Work•5/5/25, 9:49 PM

It remains part of the DurableObjectState interface to remain compatible with Workers Runtime APIs.

Hard@Work•5/5/25, 9:49 PM

IIRC because many things built for Workers expect to exist

AAvi i need to know because we have some long-running async tasks to run

lambrospetrouOP•5/5/25, 9:52 PM

Your DO will stay active after the last request up to 1-2 minutes if you have some scheduled, otherwise it will be evicted after 10 seconds.
If you want to keep it running for longer you can schedule an alarm to run every few seconds doing nothing other than checking if your long running tasks are done and rescheduling itself if not yet. Alarms count as normal requests so they reset the timer for eviction.

Llambrospetrou Your DO will stay active after the last request up to 1-2 minutes if you have so...

Avi•5/5/25, 9:53 PM

what about a pending promise?