FRare ETA detected 
BDo you only pay for the database round trip cost once with
.batch, rather than for every statement in the 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
params)BWhat's the downside with
params?VIf 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
params (as the separate json field)BAh got it.
BIf
stmt. and db. methods can throw, what's the purpose of D1Result.success? Would it ever be false
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
success is always truewithin 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 
JIt’s also pretty common for apps on Cloudflare to use both, as well as R2, etc, again just depending on the kind of data you’re storing and how you need to access it.
CD1 perf is going to be hard to measure as its a single durable object/instance running in a single region where KV is two central stores (US, EU) + heavy caching in front
NHi all. I am really often getting
{"D1_RESET_DO":true} error when trying to import db using https://developers.cloudflare.com/api/operations/cloudflare-d1-import-databaseNany insights into what could be going on?
Mno - the bookmarks time travel uses are like pointers rather than actual copies of the DB, makes it hard to do stuff like that
i initially wanted to build a Time Machine style UI for it, but it wouldn't work
i initially wanted to build a Time Machine style UI for it, but it wouldn't work
Mthat's a pretty bad error on our part, if i had to guess it's hitting an error and rolling back, does it work if you call the /query API with the sql text directly?
N@Max (@rozenmd) problem is that this DB is giving error all the time
Nno matter what I do, and wait for how long
Dsame here
DError: D1_ERROR: Invalid primary location hint provided
Osame here, all services using D1 are down
D
rip d1Oback up it seems
Dyep, getting results from my dbs now
Msame here, got good a few minutes ago
DLooks like it’s resolved now, but I’ll see if we can get a retro statuspage for this
VIs Cloudflare team playing with our production databases in the backend
Dsee above
VI think the D1 was out of beta few months back, still these issues regularly.
MThere was a bad release at 08:42 UTC, we have since rolled it back.
SI've noticed that my d1 has become really slow.
A simple query where i loaded client information took only 20ms, where now it takes almost 300! i didn't change anything. we have multiple tenants, and this can be seen on the dev env and the prod env
Edit: All DBs are hosted in WEUR, where all our tenants are. smart placement is enabled for worker
A simple query where i loaded client information took only 20ms, where now it takes almost 300! i didn't change anything. we have multiple tenants, and this can be seen on the dev env and the prod env
Edit: All DBs are hosted in WEUR, where all our tenants are. smart placement is enabled for worker
AMy startup recently got funded, and since i am cloudflare boy, i am already using majority of its services now i was thinking wether i should also use D1 as my main Database or not?
-> why i was thinking of D1?
= Since i am going to use workers for API and smart placement is also available, so using D1 would bring my api and Database closer making the query load faster.
-> Does D1 has limitations for startups?
-> has anyone faced problems with it and decided to change their DB
My use case ( not exact, just a example )
-> User will have multiple relationships in the table
-> Analytics
Thats it. please guide me if you can from your experience.
Thank you
-> why i was thinking of D1?
= Since i am going to use workers for API and smart placement is also available, so using D1 would bring my api and Database closer making the query load faster.
-> Does D1 has limitations for startups?
-> has anyone faced problems with it and decided to change their DB
My use case ( not exact, just a example )
-> User will have multiple relationships in the table
-> Analytics
Thats it. please guide me if you can from your experience.
Thank you
Mwhat's your database id, any chance the table just has more data without an index on the queried key?
Swe have a database for each tenant, in my test database we only have 4* entries in the table of concern. id is: 7b0f67f7-6768-44a8-a855-08e758a65989
Mwhen you say it takes almost 300, do you mean as measured from the Worker? I don't see evidence of that kind of performance regression in that DB
Malso, how much traffic is this DB doing? smart placement relies on steady traffic to place your Worker optimally
Syep, i measuered the time within the worker. it always was around 20ms before.
should i disable smart placement? database is in WEUR anyway and all our traffic (should) come from germany
should i disable smart placement? database is in WEUR anyway and all our traffic (should) come from germany
Sdashboard doesnt show any smart placement traffic, only default placement, so maybe not enough traffic