Ye its production ready. 25 billion rows read included in pro
Ye its production ready. 25 billion rows read included in pro
YI am talking about concurrent read limit per second.
YCan it handle e.g. 100k users hitting database at the same time.
Bsame : concurrent limit for same row ,a nd limit for same database
BIt's not replicated (yet) and uses Durable Objects under the hood, so it's single-threaded and has a soft limit of 1,000 requests per second. It won't be able to handle 100k concurrent users.
Yjust to clarify, d1 has a limit of 1k read / seconds and 1k write per seconds ?
B"An individual Object has a soft limit of 1,000 requests per second"
BThere's no exact D1 limits but as it's essentially just a Durable Object then the DO limits apply
RBuy why they didn't show it in their docs D1 -> Limits (https://developers.cloudflare.com/d1/platform/limits/) ? It's a huge deal.
UThere isn’t really any hard limits it heavily depends on your app and the queries you do
MYou would likely want Hyperdrive for that level of scale.
1Even though I liked what the guy said about cynical comments, marketing people are using every social engineering thing they can to make you buy their 
, this is equivalent to scam.
, this is equivalent to scam.1there is a reason we have a link to documentation in the channel description instead of the landing page https://www.cloudflare.com/developer-platform/d1/
1the landing page is basically nonsensical, just say anything as long as its unlimited, natively distributed in the cloud and blazingly fast
1especially relevant to cloudflare with the recent drama about that marketing girl getting fired
1very on point lol, "infinite scalability"
1"D1 is overloaded"
1marketing™
Bweird, i remember stress testing d1 and it handled it completely fine
Blike 5 k inserts /s
1maybe they started getting customers after stabilization
ADo you have an index on the
service column?AOr is the table not huge?
AHow many rows?
Ahmm okay then I have no idea
A3 more time
FMonths? Still on alpha?
AThey sent your DB to the moon
HYou have a ticket?
IHow many rows is that table?
IWait, so it's a write to a single row updating a single value?
IAnd the column you use for the filtering is indexed?
IThat shouldn't take that long.
IYeah, the actual DB time is 0.3ms in that one.
ICan you get one with the time high?
II'd presume the values are the ones listed in the graph
INote that
Date.now() on Workers updates only on I/O, so might not update or be unrelated to the single query.IIs it a scheduled Worker?
IOh, I see.
IAnd can you try, just out of curiosity to re-deploy the Worker (unless you already tried, didn't read the whole convo)
IGotcha
IThen yeah, probably worth looking into it @Max (@rozenmd)? 
Mone sec, theres a lot of scrollback and irrelevant stuff to filter
M11:16am in which timezone?
Mcan you DM me your account id?
Myeah actually
NHello,
I understand that D1 is known for its excellent
Do you know where I can find comprehensive information about the performance of writes and the locking mechanism when executing
If you know of any resources where I can find consolidated information, including findings from official documentation and other blogs, please let me know.
I understand that D1 is known for its excellent
read performance and scalability, but I'm uncertain about its write performance.Do you know where I can find comprehensive information about the performance of writes and the locking mechanism when executing
db.batch() (whether it uses file locks, table locks, record locks, etc.)?If you know of any resources where I can find consolidated information, including findings from official documentation and other blogs, please let me know.
AThere's no read replication yet so I wouldn't say it's know for it's excellent read performance. Or at least, it should not be known for that (right now, we'll see what happens in the future)
