LNext question, when does this come to DO-based SQLite storage?
LD1 is the customer zero of DOs 
So, once we see it's good enough with D1 and iron out some things, DOs will get some version of it too.
So, once we see it's good enough with D1 and iron out some things, DOs will get some version of it too.LI would encourage people to try this out, and please give us feedback. Tell us cases it broke for you, or didn't do what you expected. Note that it's "beta". We are aware of some specific issues and are fixed as we speak to be rolled out over the next few weeks, so do your own testing to see if fits your workloads too.
CIMO at least for me the session API adds waaay too much work to bother implement it. Ideally I was hoping cf would just figure this out like turso does
CRight now I simply use cache & KV which give me pretty much the same results but it's simpler and easier to understand (I know it's eventually consistent, but that works for me)
LIf you are fine with normal eventual cache, then keep with that, and it fits better. Global consistency has tradeoffs, either exposed to the user and you decide the queries you want consistent, or it's always done implicitly and then you get slower performance across the board.
LWhich Turso feature specifically? I am aware of the embedded replicas but that's a whole other thing/use-case.
CThey used to have multi region replicas, but from the homepage it looks like they discontinue it
LIn what way is it too much work? It looks like it's a few lines of code tweak? That may be more work than continuing to use your own cache+KV solution, but for anyone who hasn't already built that, it seems like adopting the session API is a lot LESS work than building something like you've done.
CMaybe it's actually very little work, I've just quickly looked at the api, but it seems like I need to read incoming headers, tweak how drizzle interacts with the db, set a new header, etc.
With KV, I just do if (kv) return kn else return d1
The other advantage is that is not vendor lock in, I can switch to any other sqlite provider (like turso) with a single line change
With KV, I just do if (kv) return kn else return d1
The other advantage is that is not vendor lock in, I can switch to any other sqlite provider (like turso) with a single line change
Cbut anyways, I wasn't really complaining, I love d1 and cloudflare, was more like my personal feedback
BTangentially, hoping for DO dynamic relocation.
LYou mean relocation of the replicas in other places, or more replicas in specific places, or relocation of the primary?
And do you need it dynamic based on traffic/requests, or you specifying that?
And do you need it dynamic based on traffic/requests, or you specifying that?
BRelocation of the primary, either manually specify or automatic like worker smart placement.
BReplicas would be nice too but I imagine it would have a similar design to D1 so it would take some effort to make use of it.
IAnd here you go Zack, read replicas are here 
II was trying to give you a hint the other day without saying anything I wasn't allowed to :lul:
ZYea, it makes more sense now, but in a way that's slightly sad because the replicas are just statically placed in all regions rather than dynamically in more places based on load 
ZHowever, very happy it's here, and sounds like dynamic placement is something they want to bring in the future 
IYeessss except:
currently one in each supported D1 regionSo right now they're static but they're static in everywhere D1 can even be
IIf they were dynamic they'd just be dynamic within those same regions.
ZYea, I get it
Zmuch nicer than having to place them in all regions ourselves, and as I said, improvements will come and will be great to see them!
WSouth América is also not invited to the party…. No Replicas here. We all of our D1 calls are router to US.
CNeed Durable Objects there first. CF was talking about getting DOs in South America and India, would be nice
Lbut in a way that's slightly sad because the replicas are just statically placed in all regions rather than dynamically in more places based on loadSmarter placement is on the roadmap
We will iterate on it over the next few weeks/months based on your feedback. Many ideas how to make placement better.
Aeyyyyy
Gis there a list of where DO is available?
Cbroad regions are documented here: https://developers.cloudflare.com/durable-objects/reference/data-location/#supported-locations-1 with ^2 next to not supported currently regions
Cloudflare Docs
Jurisdictions are used to create Durable Objects that only run and store data within a region to comply with local regulations such as the GDPR or FedRAMP.
Cthere's a community site for showing where DOs spawn from each cf location/which CF locations support DOs: https://where.durableobjects.live/colo/GRU
Where Durable Objects Live
Tracking where Durable Objects are created, wherever you are in the world.
GThank you 
MNot sure about 1, but for your question about replication, yes, there is a cold start for non-active replicas. We only replicate to actively running replicas. If we were always replicating the primary's latest state, then we'd have to keep your replicas hot in memory, in which case you'd be paying for duration, even if you weren't using it.
Ldoes the storage pricing change at all? Right now I think it's something like .75 per GB. Does that get multiplied by the number of replicas or is the replica pricing baked in?No! Replicas are not charged extra.
Sguys, is there something wrong with D1?
SMy python app that pushes using the api has been getting a lot of
LThis was 2 hours ago right? There was a small blip of HTTP errors for a few minutes that is fixed already: https://www.cloudflarestatus.com/incidents/20rzplhpvcsz
SWeird cause Im still having issues
Sno errors but Im pushing stuff to D1
Sand my workers pages api still doesnt show them
SI can't check the db right now to see if they are there
SAre you also Greek?
Athis chart on the blog post gives me the impression that read replicas will pretty much always be under a second behind the primary.
is this impression accurate?
is this impression accurate?
Aalso, when the sessions api was announced last year, IIRC it was stated that if you used the old (non-session) D1 api, the behaviour would be the same as it is without replication (always go to the primary) but now this graphic suggests otherwise. did this change?
Cthe bottom left of that graphic "With using Sessions api"
Aoh wrong graphic
Ameant this one
Aoh unless this is saying not using the session api (on a replica-enabled db) would be equivalent to using the sessions api with
first-primary?