how much slower is it to use sql reads directly instead of keeping an in memory `Map` copy of the t

how much slower is it to use sql reads directly instead of keeping an in memory

Map

Map

copy of the table to look up by PM?
Obviously in memory is going to be effectively instant but it's already a hassle to update data in both sql and in memory.

NNeed_Not how much slower is it to use sql reads directly instead of keeping an in memory ...

lambrospetrou•11/1/25, 9:17 AM

If you use SQLite DOs there is already an in-memory cache of your reads, so the difference should be negligible. Using in-memory state could make sense within the context of a single request but otherwise it should be fast enough.

NNeed_Not how much slower is it to use sql reads directly instead of keeping an in memory ...

Larry•11/1/25, 9:36 AM

I switched away from keeping instance variables (with a rare exception) a year or so ago and it was one of my best design decisions. We noticed no bump in cost because reads are so cheap and as you pointed out, you already need to do the writes. We noticed no performance penalty. We didn't know how to measure it but we suspect that cold starts got faster by a few ms, although we now believe that's driven by the size of the SQLite storage.

ALECKS•11/1/25, 2:21 PM

Has there been any discussion/consideration around adding some built in lifecycle hooks to Durable Objects? For example, these two would be super helpful:

async onWake() - called automatically after a DO is instantiated
async onEvict() - called automatically right before a DO is evicted

My current pattern is to call onWake() myself, but every time the DO is accessed, and it has a flag internally to check if it's already awake. Works, but annoying ergonomics.

For evict, this is trickier, I currently do not know how to catch this. Having this OOTB would allow us to keep DB connections open between multiple requests while the DO is active and serving. Right now, I have to open and close a pg connection for each request which isn't ideal.
I suppose I could use a setTimeout and close when that expires, and reset the timeon on each new request... but that also feels weird.

How are people solving this pattern?

Sstickman `onWake` is essentially equivalent to calling your `constructor`? I remember the...

ALECKS•11/1/25, 2:25 PM

The big problem with that is doing any sort of async work in the constructor, like initializing state with same data from a postgres call

Sstickman you can do async work inside `blockConcurrencyWhile`

ALECKS•11/1/25, 2:26 PM

in a constructor?

ALECKS•11/1/25, 2:27 PM

Oh yeah.. hmm even the docs show it: https://developers.cloudflare.com/durable-objects/reference/in-memory-state/

ALECKS•11/1/25, 2:28 PM

ok, that's great, missed this before

AALECKS ok, that's great, missed this before

Larry•11/1/25, 3:43 PM

BTW, I've been using Durable Objects for about 4 years now and it was just last week when I learned something new about it.

LLarry BTW, I've been using Durable Objects for about 4 years now and it was just last ...

ALECKS•11/1/25, 3:46 PM

hey since you have so much experience, curious... for DOs that need an identity, for ex, let's say you have a DO per tenant

ctx.DO.getByname(tenantId)

ctx.DO.getByname(tenantId)

since you can't know the state ahead of time, is this really the only way to call methods on it:

// first, tell it who it is
await stub.init(tenantId)

// then do the work
await stub.doStuff()

// first, tell it who it is
await stub.init(tenantId)

// then do the work
await stub.doStuff()

or is there some clever way to initialize a worker once, and not have to redo it every time?

AALECKS 🙂 hey since you have so much experience, curious... for DOs that need an ident...

James•11/1/25, 3:59 PM

I send the id as metadata on every rpc call since any given worker may or may not be initializing the DO given its a singleton.

AALECKS 🙂 hey since you have so much experience, curious... for DOs that need an ident...

Larry•11/1/25, 6:17 PM

You can't know it's name without doing something like James suggests or what you suggest with

.init

.init

. However, depending upon why you need it, you may just be able to get away with using

ctx.id

ctx.id

That address is always accurate and always present. It's that 64 hex digit string that you would use in

get(idFromString(id))

get(idFromString(id))

or maybe it's the actual id object so you'd use

get(id)

get(id)

. I let TypeScript tell me when I get it wrong and I'm on mobile so can't try it.

Most of the time, I only need that because I'm using it as the return address for something like @lumenize/proxy-fetch.

There is also another trick I use essentially every time now. I almost always use WebSockets from a browser. My

routeDORequest

routeDORequest

expects this format for URLs,

[/${prefix}]/${doBindingName}/${doInstanceNameOrId}[/path...]

[/${prefix}]/${doBindingName}/${doInstanceNameOrId}[/path...]

. That's always how my WebSocket upgrades happen so I always have the name in that

doInstanceNameOrId

doInstanceNameOrId

slot. There is also an undocumented header (I just added it and it's on my to-do list to document) that has it as well, in case you don't want to parse the URL again inside your DO's fetch handler. Since you have to use fetch for WebSockets and I'm always using WebSockets, I always have those.

AALECKS 🙂 hey since you have so much experience, curious... for DOs that need an ident...

lambrospetrou•11/1/25, 7:55 PM

Personally, I either do the

init()

init()

approach, or send the identifier all the time if the original request also contains the information to derive it.

Sstickman you can do async work inside `blockConcurrencyWhile`

lambrospetrou•11/1/25, 7:57 PM

Keep in mind that just because you can do it, you should not do slow operations in the constructor.
While you do that you literally cannot process anything, so with sufficient traffic you will be overloading your DO potentially.

Ideally the constructor should only do light initialization, reading from its storage if needed, or some other "fast-ish" action. Reading from a remote database could take hundreds of milliseconds potentially, so do it if absolutely necessary but be careful and monitor the latency.

Llambrospetrou If you use SQLite DOs there is already an in-memory cache of your reads, so the ...

Need_NotOP•11/1/25, 9:42 PM

does that apply to SQL too? I can see if KV is cached but sql?

<@235148962103951360>•11/2/25, 4:19 AM

Does running durableObject.fetch count as a billable request?

NNeed_Not does that apply to SQL too? I can see if KV is cached but sql?

lambrospetrou•11/2/25, 7:46 AM

Yes, all storage operations use the underlying SQLite engine when using SQLite DOs, therefore benefit from in-memory cache by the runtime already where applicable.

Need_NotOP•11/2/25, 7:50 AM

That's good.

Need_NotOP•11/2/25, 7:54 AM

too bad there is no way to set multiple alarms. I want an alarm for additional work after returning. But also an alarm to clean up and delete everything after inactivity.

Sstickman Yes, every RPC/fetch on a Durable Object is one billable session.

<@235148962103951360>•11/2/25, 7:54 AM

thanks for your response

NNeed_Not too bad there is no way to set multiple alarms. I want an alarm for additional w...

Larry•11/2/25, 12:17 PM

There are several solutions for this running around. They all work off the same basic concept. They store your alarm specifications in DO storage. This can be quite complicated with recurring alarms specified as well as multiple single alarms in the future. The key is that they make sure the next alarm, according to that stored specification, is the one that the single native alarm is setup for. Smart implementations make sure that if you somehow missed an alarm, it'll get caught and executed-maybe a little late, but not missed. They also have retry logic.

The

agents

agents

package has such a system and it's documented, but unfortunately, you have to adopt the somewhat rickety and spotily-documented Agents ecosystem to use it. There is Brayden's elegant Alarm class but it's not documented, and by default requires your DO extend the Actor base class unless you duplicate what that base class does manually. It's still my favorite implementaion and can be found at

@cloudflare/actors

@cloudflare/actors

on npm. And PartyKit has one as well.

Internally, we used the PartyKit one for the 5 minutes we were using PartyKit, then we created our own, now we use a fork of Brayden's. I had on my to-do list to release a well-documented stand-alone package that is pluggable based upon Brayden's implementation. I'll move that to the top of the list for Lumenize and you should have something in a day or so.

NNeed_Not too bad there is no way to set multiple alarms. I want an alarm for additional w...

Larry•11/2/25, 12:23 PM

As a thought... based upon your use of "additional work after returning", what are you "returning" from? The reason I ask, that there is

@lumenize/proxy-fetch

@lumenize/proxy-fetch

which offloads Requests to a Worker or a dedicated DO and then when the fetch is done, it calls back to the original DO and executes a handler that you provided when you made the original

proxyFetch()

proxyFetch()

call.

Introduction | Lumenize

Cost-effective external API calls from Durable Objects using Cloudflare Queues

NNeed_Not too bad there is no way to set multiple alarms. I want an alarm for additional w...

Larry•11/2/25, 1:30 PM

Actually, I just looked at our Alarms port and it looks like the only thing we did was add a Lumenize NADIS (not a DI system) wrapper around it. So, instead of rushing that to market, I'm now working on docs for Brayden's Alarms. I should have that out later today.

ALECKS•11/2/25, 1:31 PM

I think the Cloudflare Agent class has that kind of Alarm system

plgingras88•11/2/25, 1:39 PM

Larry you deserve a wage from CF !

plgingras88•11/2/25, 1:40 PM

Thanks for your precious involvement, I read and take great interest in your work

Pplgingras88 Thanks for your precious involvement, I read and take great interest in your wor...

Larry•11/2/25, 2:05 PM

That makes it all worth it.

AALECKS I think the Cloudflare Agent class has that kind of Alarm system

Larry•11/2/25, 2:07 PM

It does. I included a mention of it in my reply but switching to Agents is a big commitment and I don't trust it since they let a security-relevant bug go unfixed for months

ALECKS•11/2/25, 2:08 PM

Yeah, I pulled the individual methods out instead of using the whole thing

LLarry There are several solutions for this running around. They all work off the same ...

lambrospetrou•11/2/25, 5:09 PM

There is Brayden's elegant Alarm class but it's not documented, and by default requires your DO extend the Actor base class unless you duplicate what that base class does manually.

You actually don't need the Actor base class. I am a fan of toolkits personally, so we tried ~~most~~ some of the functionality in the package to make it available on its own, only depending on the of SQLite Durable Objects.

See example in https://github.com/cloudflare/actors/blob/e910e86ac1567fe58e389d1938afbdf1e53750ff/examples/durable-objects/src/index.ts#L21

Same goes for the SQL Schema migrations, you can use them without the Actor base class, and retry utilities too.

Llambrospetrou > There is Brayden's elegant Alarm class but it's not documented, and by default...

lambrospetrou•11/2/25, 5:10 PM

And yes, we need to document the whole package better. It's coming.

NNeed_Not too bad there is no way to set multiple alarms. I want an alarm for additional w...

Larry•11/2/25, 6:05 PM

Here are the docs. This is the one that shows you the same thing that Lambros just did, namely how to do without extending Actor, but it has API usage docs also: https://lumenize.com/docs/actors/alarms/plain-usage

This is the same thing but using the Actor class: https://lumenize.com/docs/actors/alarms/basic-usage

Larry•11/2/25, 6:54 PM

Apologies for the doc-test format. I realize the testing foo sorta gets in the way of the key stuff. It's just the quickest way for me to write docs that I know are correct. I'll come back with more concise ones some time later.

Larry•11/3/25, 5:28 AM

BTW, this was a fun exercise. I learned more about Actors and how it implements Alarms. I also learned that testing alarms is less than ideal in 's , so I spent the rest of the day adding alarm testing support to @lumenize/testing, which requires no manual triggering of alarms. I switched the docs linked above over to using it so there is about half the boilerplate that there was before.

plgingras88•11/3/25, 11:52 AM

Unsure if this kind of topic is welcome here, but have you heard about Rivet, which presents itself like the "open source durable object" with many more features and platform agnostic ? Imagine durable object but no lock-in, no worker limitation (128Mb ram, V8 isolate, etc.), but with other features like local sync first, workflows, background jobs, rate limiting. This is not a 1:1 comparison, both have their own pros and cons, but this can be hosted anywhere, from personnal VPS to Cloudflare workers/do too. I believe (and mostly hope) this is the kind of new project that makes CF less unique and will trigger their fire team to work on missing features.

https://www.rivet.dev/

Rivet

Rivet - Build and scale stateful workloads

Rivet is a library for long-lived processes with durable state, realtime, and scalability. Easily self-hostable and works with your infrastructure.

Pplgingras88 Unsure if this kind of topic is welcome here, but have you heard about Rivet, wh...

lambrospetrou•11/3/25, 12:42 PM

Have you tried it, though? What worked better for you vs CF DOs, or worse?

Llambrospetrou Have you tried it, though? What worked better for you vs CF DOs, or worse?

plgingras88•11/3/25, 1:24 PM

I haven't yet, I just started to follow the project few weeks ago. This surely is on my bucket list whenever I get a chance. They also provide a cloud hosted solution, this may be a simple start to play with it, while I do not know anything about the cloud providers and architecture behind (e.g. : is this local disk like DOs, etc).

plgingras88•11/3/25, 1:26 PM

What I find interesting, out of the lock-in, is that I am not restreined to a middle-man worker and I could host actors on a dedicated servers with tons of CPU and RAM, where worker blocks me at 128Mb and reserves the right to share 2 instances on the same behind the scene.

Pplgingras88 What I find interesting, out of the lock-in, is that I am not restreined to a mi...

lambrospetrou•11/3/25, 1:27 PM

Self-hosting is a different game though.

plgingras88•11/3/25, 1:28 PM

Of course, but they also offer a cloud solution or even using CloudFlare and Durable objects under the hood. At the end of the day, the portability is yours to chose.

plgingras88•11/3/25, 1:29 PM

My point is, in all respect, if what they promise is right and they succeed the way they are rushing right now, Cloudflare durable objects may become the blackberry of their iphone.

Pplgingras88 My point is, in all respect, if what they promise is right and they succeed the ...

João Castro•11/3/25, 2:18 PM

Its very rare that you see competition taking over in a sweep like it happened there, and this does not look like a paradigm shift, just some welcome competition in the space

Pplgingras88 Of course, but they also offer a cloud solution or even using CloudFlare and Dur...

Larry•11/3/25, 2:35 PM

using CloudFlare and Durable objects under the hood

The notion of "write once deploy anywhere" is appealing but it's extremely challenging from many dimensions (performance, DX, etc.). Think of it as a tradeoff between portability and avoiding leaky abstractions. This would be super-leaky and it would always lag DO features.

History is littered with these sort of things that sound great at first but get in the way more than help: The Serverless Framework, SDN (software-defined network), ORMs to a degree, Xamarin (although it pivoted and became .NET 2.x+), AWS Event Bridge, Azure Event Grid, etc.

I was a consultant for a huge project at Intuit to define their own least common denominator programming language that would compile down to Java or .NET. It took years and while they were trying to make it work well, they didn't release any new products and few new features because everyone was ordered to use this new programming language and it was always a few months from being ready. In the end, they gave up but they never got back those 2-3 years of wasted effort and near zero feature velocity.

That tamed my desire for portability, and I'm much happier because of it.