if the servers are unreliable. Why even have them available
if the servers are unreliable. Why even have them available
CI'm talking about if they were to hypothetically offer D1 in non-supported regions by forgoing replication/all the other properties
Cthere is such thing as storage-less DOs in any colo we've heard about before, I forget the exact details
Cnot sure they could even do north africa, need a bunch of nearby colos/a grouping for reliability and such. South Africa and the Middle east would be cool though, hopefuly one day. When they spun up Oceanic region I got hopeful for more regions but none more yet
Ethey have 4 colos here in Algeria
Ethey have a lot of colos in Middle East
CI think they would need more then that. Look at Oceanic for example: https://where.durableobjects.live/region/oc, 4 PoPs and a total of ~9 colos or so. No idea what their exact requirements are but from the current regions, all got at least 4 PoPs with at least a few being multi-colo. It'd be cool for them to have every region covered though, one can dream
Monly if you want to lose data
Eim willing to manually back it up
MKenton explains it well here: https://blog.cloudflare.com/sqlite-in-durable-objects/#under-the-hood-storage-relay-service
Ethe issue for me is that D1 (DO) isnt ava for me in the countries/cities i need them to be in
Eif they where i'd make my own read replica solution
Mwe're working on it
EI know and i appreciate it. My concern isnt read replicas
Mno i mean running D1/DOs in more places, it'll get there, like australia
Ejust out of curiosity what are the requirements for you guys to have D1/DOs in places
Mhas to be close enough/fast enough to a certain number of colos (forgot how many)
DI'm pretty sure some of us have already said that storageless DOs would be nice to have in more locations for websocket gateways 
E^^^
Ethis would also enable us to make read replicas
Eread-replicas disappearing isnt an issue so yeah
JDynamodb cut pricing in half. Time for Cloudflare to do the same. 
VAny updates on if D1 will get jurisdictional restrictions? https://community.cloudflare.com/t/d1-location-hints-explanation-and-improvement/634791
JIs there any montioring of what queries are reading the most rows? 
MIs there a way to set upper limits on how many read/write rows per operation?
EIssues on d1 continue. New issues also coming: Cant read from request stream after response has been sent.
Internal error while starting up D1 DB storage caused object to be reset.
Network connection lost.
Etc…
Its been a month now that we receive this issues constantly .
Internal error while starting up D1 DB storage caused object to be reset.
Network connection lost.
Etc…
Its been a month now that we receive this issues constantly .
- Cant read from request stream after response has been sent.* started yesterday, and it correlates with the time that the latency issue was identified : https://www.cloudflarestatus.com/incidents/919j0tc3dmmd
MWhat's your databaseId?
Mand you haven't redeployed your Worker since yesterday?
ENo, we have stopped pushes for 3 weeks now to keep this issue tracked, so we don’t get sidetracked on where the issue is coming from
MI ask because
Cant read from request stream after response has been sentNo pushes
EAlso errors like max size reached are coming in..
VYes, we're planning for H1 2025
FRare ETA detected 
BDo you only pay for the database round trip cost once with
.batch
E:pOg:
VYou pay for rows read/written not how many calls, statements or batching.
https://developers.cloudflare.com/d1/platform/pricing/
https://developers.cloudflare.com/d1/platform/pricing/
Mthink they meant pay in the network-round trip cost sense
VAh performance wise, yea, batching better (although the downside of
paramsWhat's the downside with
paramsIf you're using the workers API for D1 batch, you're fine. But if you the HTTP API for D1 batch, you can't add
paramsAh got it.
BIf
stmt.db.D1Result.successfalse
LHie there I am using Cloudflare D1 for a project and i noticed the latency is really high around 800 to 900 ms.
resulting in overall high latency in api calls. The DB is deployed in APAC region and the worker is in colo=DEL.
Any insights on why this could be Happening?
Thanks
resulting in overall high latency in api calls. The DB is deployed in APAC region and the worker is in colo=DEL.
Any insights on why this could be Happening?
Thanks
Mthink we just used the types from the HTTP API here
BDoes that mean I can just assume
successtruewithin the Worker, yep
BGot it, probably a good idea to have it documented though.
JThey have very different use-cases. That benchmark is a bit out of date with https://blog.cloudflare.com/faster-workers-kv/ now, and KV getting even faster, but it’s going to really depend on your application.
Lots of write-once read-often key-value data? KV makes a tonne of sense. Lots of deep relational data, D1 makes more sense.
Lots of write-once read-often key-value data? KV makes a tonne of sense. Lots of deep relational data, D1 makes more sense.
JIf you can describe your app and the kinds of data/queries you’ll be doing, we can probably provide better recommendations 
