I have a bunch of DO namespaces I want to convert from KV to SQL backend, is the official migration

I have a bunch of DO namespaces I want to convert from KV to SQL backend, is the official migration process coming soon or should I just create new namespaces and migrate data?

LLarry It shouldn't hibernate when you are awaiting external fetch (what I assume you m...

Vlad Lykhonis•10/20/25, 6:51 AM

Clock time you are referring to is worker cpu time limit?

11984 Ford Laser I have a bunch of DO namespaces I want to convert from KV to SQL backend, is the...

gruntlord6•10/20/25, 6:55 AM

you finally making the jump?

Ggruntlord6 you finally making the jump?

1984 Ford LaserOP•10/20/25, 6:57 AM

Yeah I'm in quiet season at work so I finally have time to dedicate to re-architecting everything

VVlad Lykhonis Clock time you are referring to is worker cpu time limit?

Lulu•10/20/25, 7:23 AM

i believe so

11984 Ford Laser I have a bunch of DO namespaces I want to convert from KV to SQL backend, is the...

lambrospetrou•10/20/25, 7:40 AM

There isn't an ETA yet, so if you need it now, I suggest doing the migration of the data yourself for now.

Llambrospetrou There isn't an ETA yet, so if you need it now, I suggest doing the migration of ...

1984 Ford LaserOP•10/20/25, 7:54 AM

No worries appreciate the clarity. I'll use it as an opportunity to rewrite everything while I'm at it, there's been plenty of changes I can take advantage of since I first built it all

VVlad Lykhonis Clock time you are referring to is worker cpu time limit?

Larry•10/20/25, 12:54 PM

I probably shouldn't have used the word "clock". It's confusing. DOs are billed on wall clock time. However, their run length limits are CPU clock time which is an order of magnitude or two more generous when you have external fetches involved. It wouldn't surprise me if it were able to wait on a fetch for 20 minutes. You'll pay for the DO the whole time, but it would still use less than 30 seconds of CPU.

1984 Ford LaserOP•10/21/25, 12:51 AM

If I delete a DO's storage, let it evict then request the same instance, will it always spawn in the same colo? I've gotten an instance in Perth which I'd really love to move closer to home

PhoenixSpace•10/21/25, 1:00 AM

If it's being spawned off of a request, it's usually pretty sticky from my experience, but if you specify a location hint instead I've had more success with it sometimes moving to a different datacenter. Not quite sure what the spawn algorithm is because it's seemingly slightly different each time I try.

For what it's worth, when I want a DO instance near a specific point, this is pretty inefficient but I just have a worker spawn and destroy DO instances with a region hint and with slightly different names then returns the name/id of the one in the POP I want

PhoenixSpace•10/21/25, 1:01 AM

This is in ENAM though, so I don't know how it is in other regions

PPhoenixSpace If it's being spawned off of a request, it's usually pretty sticky from my exper...

1984 Ford LaserOP•10/21/25, 1:02 AM

The locations I wanna use are within the same location hint, the routing just seems to really suck in this case (going from side of Australia to the other can be awful in terms of routing). I also don't really wanna have to stray away from the current name I am using for this instance

11984 Ford Laser The locations I wanna use are within the same location hint, the routing just se...

PhoenixSpace•10/21/25, 1:02 AM

Honestly, I'd just spin a quick test worker to spin and destroy a DO like 10 times with the same name with a set location hint. YMMV but usually thats enough to get a couple of different POPs. If that works, then just do that again with the DO class and name you want until it's in the right region then use it

PPhoenixSpace Honestly, I'd just spin a quick test worker to spin and destroy a DO like 10 tim...

1984 Ford LaserOP•10/21/25, 1:03 AM

I like it thank you

PhoenixSpace•10/21/25, 1:03 AM

np and please let me know how it goes. I haven't experimented with coercing DOs to specific POPs outside of ENAM/WNAM and would love to know if that hack works elsewhere lol

PhoenixSpace•10/21/25, 1:04 AM

My old trick was to spin a lambda instance in a nearby AWS center and hit the endpoint...

PPhoenixSpace np and please let me know how it goes. I haven't experimented with coercing DOs ...

1984 Ford LaserOP•10/21/25, 1:05 AM

Its never been a problem before, normally get them always in Melbourne which is close to home. There's only a 33% chance a DO will spawn in Perth via Melb instead of Sydney so I just got unlucky with this one. I will test out hitting the same instance and see how I go

11984 Ford Laser Its never been a problem before, normally get them always in Melbourne which is ...

PhoenixSpace•10/21/25, 1:07 AM

That makes sense. I'm working on a small tool that I'll need to put small DOs in very specific areas (one of which is in Australia) so I've been playing around more and more with forcing the DO placement algo where I want lol. I kinda wish CF could just let me specify the IATA code of where I want it, but I'm guessing there are architecture limitations there

1984 Ford LaserOP•10/21/25, 1:09 AM

So to confuse myself more, I just requested a new instance (first one was named '2025', this one is '2026') and it ended up in the same colo but with far better response times when hot?? Def need to test this out more

1984 Ford LaserOP•10/21/25, 1:09 AM

These instances are also entirely fresh with no data stored beyond the runtime-abstracted stuff

11984 Ford Laser If I delete a DO's storage, let it evict then request the same instance, will it...

Isaac McFadyen•10/21/25, 1:10 AM

As far as I remember, yes.

1984 Ford LaserOP•10/21/25, 1:10 AM

2025 gives me around 350ms when hot, 2026 gives me around 150ms which is not insignificant. Both in Perth

PhoenixSpace•10/21/25, 1:10 AM

How are you measuring the colo it's running in?

1984 Ford LaserOP•10/21/25, 1:10 AM

Just from the CF logs

Isaac McFadyen•10/21/25, 1:10 AM

In fact if I remember correctly once you create a DO with a specific name it's always in that colo even if you delete, evict, and recreate a while later (not 100% but that's what I remember).

PhoenixSpace•10/21/25, 1:11 AM

Interesting

PhoenixSpace•10/21/25, 1:11 AM

That's also pretty annoying

PhoenixSpace•10/21/25, 1:11 AM

My habit of completely not caring about my DO names and making them random numbers or UUIDs comes in handy once again!

1984 Ford LaserOP•10/21/25, 1:12 AM

Its just annoying cos I have a bunch of data that I want to associate to a specific year, I can rearchitect around it but would rather not

PPhoenixSpace My habit of completely not caring about my DO names and making them random numbe...

Isaac McFadyen•10/21/25, 1:12 AM

If you do this I highly recommend using newUniqueId() rather than idFromName() if you can, it saves a round trip

11984 Ford Laser 2025 gives me around 350ms when hot, 2026 gives me around 150ms which is not ins...

PhoenixSpace•10/21/25, 1:12 AM

I've had this happen before, and I genuinely have no idea what causes it. Maybe different machines or something? But also usually for me when it happens, sometimes when its recreated out of idle later the latency changes again

1984 Ford LaserOP•10/21/25, 1:12 AM

I'll wait a bit and see if I get similar results

IIsaac McFadyen If you do this I highly recommend using newUniqueId() rather than idFromName() i...

PhoenixSpace•10/21/25, 1:12 AM

Oh interesting, I didn't know that. Thanks for the tip!

PhoenixSpace•10/21/25, 1:13 AM

rn my scheme is usually [IATA of incoming request worker]-[DO type/name]-[some sort of short random number or UUID] so that in logs it shows up a little nicely, but I think I'm just going to go full IDs now

Isaac McFadyen•10/21/25, 1:14 AM

Yeah basically if you use the

idFromName

idFromName

the runtime has to check (globally) whether the DO exists already whereas if you do

newUniqueId

newUniqueId

it's generated in a way that it will always be unique and doesn't need to do that double-check

PhoenixSpace•10/21/25, 1:14 AM

Oh that makes... a lot of sense. The more you know

PPhoenixSpace Oh that makes... a lot of sense. The more you know

1984 Ford LaserOP•10/21/25, 1:15 AM

There's a note about it here for reference: https://developers.cloudflare.com/durable-objects/api/namespace/#newuniqueid

PhoenixSpace•10/21/25, 1:16 AM

Ah, I never used newUniqueId so I guess I missed that. Thanks for the link!

PhoenixSpace•10/21/25, 1:21 AM

Looking over the docs again, I am actually kind of curious why there isn't a way to spawn a DO at a specific location or minimal latency to a specific CF POP. I wonder if it's a engineering limitation or just lack of demand (I'm guessing I will probably never get a specific answer)

PPhoenixSpace Looking over the docs again, I am actually kind of curious why there isn't a way...

1984 Ford LaserOP•10/21/25, 1:24 AM

Probably just to stop people absolutely spamming new instances in 1 pop

PhoenixSpace•10/21/25, 1:26 AM

lmao

PhoenixSpace•10/21/25, 1:26 AM

yeah fair enough

PhoenixSpace•10/21/25, 1:27 AM

back to spinning up lambda instances to pre-emptively create DOs :)

1984 Ford LaserOP•10/21/25, 1:28 AM

I'm actually wondering if this is related to my ISP in some way, I'm getting directed to Perth on other Workers not at all related to DOs

PhoenixSpace•10/21/25, 1:28 AM

It very well could be. Maybe your ISP is peered with an interchange in perth?

PhoenixSpace•10/21/25, 1:28 AM

Easy solution is to check https://workers.cloudflare.com/cdn-cgi/trace :P

1984 Ford LaserOP•10/21/25, 1:30 AM

I just got Adelaide which is different again :NotLikeThis:

PhoenixSpace•10/21/25, 1:30 AM

That's so weird

PhoenixSpace•10/21/25, 1:30 AM

For what it's worth, my ISP sends my requests to a datacenter ~400 miles away from me, ISPs are just weird

PhoenixSpace•10/21/25, 1:31 AM

ime it's just luck whether or not your ISP is sane with routing