@1984 Ford Laser Thank you! But that is for every worker location + durable object combination... n

@1984 Ford Laser Thank you!
But that is for every worker location + durable object combination... no way to prevent this?
I mean what is the point of a very fast vertical and horizontal scaleble DB that needs 1s+ cold start on every 280+ server for every DB, every 5 seconds? wtf...

FFernando Barroso Hello! Does anyone know how long limit increase request takes? I submitted a req...

DaniFoldi•2/27/25, 12:55 PM

I don't think that specifically the sqlite size limit can be increased today, sorry

DDaniFoldi I don't think that specifically the sqlite size limit can be increased today, so...

boop•2/27/25, 1:59 PM

I’m going to assume that he means the account storage limit

Good•2/27/25, 2:05 PM

can i have some durable object limit just to test things out something its for a school i would appreciate if you guys can help out

Original message was deleted

Good•2/27/25, 3:01 PM

imagine using paid worker program for testing out starbase db and testing out stuff

Good•2/27/25, 3:01 PM

i am not even sure will be using do but it seem great product

Original message was deleted

Good•2/27/25, 3:53 PM

it is but you can atleast set some minimum limits for dev purposes though very helpful

Good•2/27/25, 3:54 PM

i can just request / suggest but you have to try if you do not try you won't know

Original message was deleted

Good•2/27/25, 3:56 PM

can you please look into this https://starbasedb.com/ and confirm i can test this out locally

Good•2/27/25, 3:56 PM

i couldn't find anything the main page is just deploy and connect

SSuper Morris @1984 Ford Laser Thank you! But that is for every worker location + durable obj...

1984 Ford Laser•2/27/25, 8:47 PM

What? They don't restart 280+ instances because each DO instance is only located in 1 colo at a time. You severely misunderstand the platform

11984 Ford Laser What? They don't restart 280+ instances because each DO instance is only located...

Super MorrisOP•2/27/25, 9:05 PM

while testing yesterday we requested a worker from different locations subsequently and there where cold start times of 1+ seconds from each location. might have been bad timing... today we saw that it only needs to cold start once for each DO instance globally, however about 30seconds later the same thing... so still 1 second of wait for each DO that is idle for more than 30 seconds... thats just stupid for our use-case.
we will use neon + hyperdrive for now.... 15-30 ms read and write. both from us and eu (for a eu hosted db)... no cold starts

SSuper Morris while testing yesterday we requested a worker from different locations subsequen...

1984 Ford Laser•2/27/25, 9:12 PM

Sounds like you are better suited to a single DB versus lots of smaller DBs via DO, not every backend architecture will be suitable for DOs

Iggy•2/27/25, 9:43 PM

I have a very basic worker + sqlite backed DO that is reading 10 rows. I'm getting ~150ms in round trip time from it (the SQL duration is <1ms), and coworkers across the country are getting >=600ms consistently, even when hitting local data centers. Shouldn't they all be roughly the same time? What's causing the huge discrepancy?

IIggy I have a very basic worker + sqlite backed DO that is reading 10 rows. I'm getti...

1984 Ford Laser•2/27/25, 9:47 PM

Are your coworkers hitting the same DO instance as you? Instances exist only in 1 colo so maybe they are seeing an unfavourable route to the instance, maybe get them to request a new instance, provide a location hint, and see if they get faster times

Iggy•2/27/25, 9:48 PM

We're both executing the exact same curl if that's what you're asking?

1984 Ford Laser•2/27/25, 9:48 PM

I mean when you do

idFromName()

idFromName()

are you both requsting the same name?

Iggy•2/27/25, 9:48 PM

Yeah

1984 Ford Laser•2/27/25, 9:49 PM

Get them to try a new unique ID and see if they still get the same timea after multiple requests. First request to new DO will be kinda slow, but should be faster aferwards

Iggy•2/27/25, 9:50 PM

Hrm maybe I'm misunderstanding, but if I have data peristently stored in sql for that given name, isn't it going to be gone if I use a new name?

1984 Ford Laser•2/27/25, 9:51 PM

oh yes of course lol I am just thinking that your coworkers are further away from the instance, or their ISP is taking longer to route the request

Iggy•2/27/25, 9:51 PM

I definitely think I'm confused lol

Iggy•2/27/25, 9:51 PM

Durable Objects do not currently change locations after they are created1. By default, a Durable Object is instantiated in a data center close to where the initial get() request is made. This may not be in the same data center that the get() request is made from, but in most cases, it will be in close proximity.

if I do the initial request in ATL, does that mean somebody in SEA is actually going to ATL?

1984 Ford Laser•2/27/25, 9:52 PM

yes

Iggy•2/27/25, 9:52 PM

their cf-ray is -SEA but it sounds like it's an internal hop from SEA to ATL?

Iggy•2/27/25, 9:52 PM

am I totally using DOs incorrectly then?

Iggy•2/27/25, 9:53 PM

my goal is to have isolated SQLite databases per

idFromName(foo)

idFromName(foo)

, but low latency based on user location*

1984 Ford Laser•2/27/25, 9:53 PM

You would need to create each user's instance with a location hint the first time its requested

Iggy•2/27/25, 9:53 PM

IOW if I have multiple geolocations hitting the same

id

id

, it's not actually running closest to each of them, it's running closest to the first requestor?

1984 Ford Laser•2/27/25, 9:54 PM

yes, probably

1984 Ford Laser•2/27/25, 9:54 PM

obvs no guarantees of anything lol

Iggy•2/27/25, 9:54 PM

ah man ok

Iggy•2/27/25, 9:54 PM

that... kinda changes everything. I was under the impression they were all executing closest to the user

1984 Ford Laser•2/27/25, 9:54 PM

A Worker does, DOs not necessarily

Iggy•2/27/25, 9:55 PM

but does that matter if my worker is just a proxy to a DO?

1984 Ford Laser•2/27/25, 9:55 PM

Can any orange names provide any timelines on being able to re-locate DO instances?

Iggy•2/27/25, 9:55 PM

I have an EA I can ask if it's secret

Iggy•2/27/25, 9:56 PM

i'm trying to create shared state across many geolocations and it sounds like that's not possible right now

1984 Ford Laser•2/27/25, 9:56 PM

For shared state you would wanna use a single instance, or persist state across multiple instances which is not the easiest to manage

1984 Ford Laser•2/27/25, 9:56 PM

D1 with upcoming replication might be the eventual solution for you

Iggy•2/27/25, 9:57 PM

good thing all of our servers are in one single location lol

Iggy•2/27/25, 9:57 PM

well, mostly.

1984 Ford Laser•2/27/25, 9:58 PM

I wonder if your coworkers get the same wall times if they simply pull a stub from the worker and the DO does something simple like print to console. This would help determine if its related to routing or something else DB related

Iggy•2/27/25, 10:00 PM

yeah i'm going to try that real quick

Iggy•2/27/25, 10:01 PM

that means I wont get the benefit of the data replication though

Iggy•2/27/25, 10:04 PM

what's the goal for dynamic relocation?

IIggy that means I wont get the benefit of the data replication though 😅

1984 Ford Laser•2/27/25, 10:08 PM

What data replication? DOs aren't replicated

Iggy•2/27/25, 10:09 PM

yeah i think i just really misunderstood

Iggy•2/27/25, 10:09 PM

I was under the assumption that DOs were always executed closest to the user, and sqlite-backed ones have shared data across all of them

1984 Ford Laser•2/27/25, 10:10 PM

Nah every instance is entirely unique to one another. Geolocation isn't a good way to split DOs, doing it per user or account or something is the way to go

Iggy•2/27/25, 10:11 PM

tl;dr is that i'm trying to build globally distributed ssr, where ssr data resolution is sqlite backed

@1984 Ford Laser Thank you! But that is for every worker location + durable object combination... n

Similar Threads

Similar Threads

Similar Threads