think we just used the types from the HTTP API here
think we just used the types from the HTTP API here
BDoes that mean I can just assume
successtrue
Mwithin 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}any 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
Msmart placement uses 1% of your traffic to compare timings (so 99 get smart placed, 1 is left default placement as a baseline), it sounds like it needs a bit more traffic yeah
Sim just wondering because even our tenant has this problem where traffic should exist, more than our dev deployment ever had even while testing
Sfunny thing to say: "yeah you just need to use the app more so it becomes faster" lol
LCan you check your placement status for your worker? https://developers.cloudflare.com/workers/configuration/smart-placement/#placement-status
I think you also need to do multiple roundtrips from your worker to the database, otherwise it cannot get much faster anyway if it's a single request.
I think you also need to do multiple roundtrips from your worker to the database, otherwise it cannot get much faster anyway if it's a single request.
N@Max (@rozenmd) will smart placement slow down (as it's doing more requests) workers that don't have a lot of traffic?
Myou may have misunderstood what I wrote, smart placement doesn't do more requests, it requires more requests for better data
LIt's not doing more requests. It just uses 1 out of a 100 of your requests with smart placement disabled, so that it can compare that with your other 99 requests that are smart placed to figure out if it's worth it doing the smart placement or if it should "smart place your worker" elsewhere.
But always check the placement status to see if you are actually smart placed.
But always check the placement status to see if you are actually smart placed.
Swill do, wait a moment
SINSUFFICIENT_INVOCATIONS - so yeah... how many are needed? :D
N@Max (@rozenmd) @lambrospetrou got it. Thank you
JI personally wouldn't use D1 as a primary due to the nature of D1 being so far from potential workers depending on your user base, the latency isn't good. During my own testing the extra 100-500ms latency per worker request due to multiple round trips to D1 wasn't worth it.
It forced me to use the DO SQL engine instead and refactor my app to per-user DBs which I feel is a more scalable design.
It forced me to use the DO SQL engine instead and refactor my app to per-user DBs which I feel is a more scalable design.
Ehow/why are you doing multiple round trips to D1?
