Hey I was wondering if the 50k d1 DB per account limit could be raised for #workers-for-platforms cu
Hey I was wondering if the 50k d1 DB per account limit could be raised for #workers-for-platforms customers
LYes we can raise that limit when there are legit reasons. If you reach to your account manager they should get it routed to the right folks.
KI was just trying to create a new migration file but the command kept complaining that the binding does not exists. Then I found out that it needs database_id in the config. Making it optional does not help in this case.
LThis was from a recent change I believe to make "auto provisioning" resources possible in wrangler for new projects where their wrangler config only contains binding names. I will mention it to the team, though.
What is the exact command you ran?
What is the exact command you ran?
AWhat’s the best auth setup with d1? I want to add auth to my Nextjs app and have considered using supabase for auth and d1 for everything else. Is this a good approach or do you recommend something different?
LDo you mean authenticating your requests TO D1, or using D1 as your database storing authentication data to some other API/service?
If the latter, you should make sure that the load would be less than 1k/second to avoid overloaded issues.
If the latter, you should make sure that the load would be less than 1k/second to avoid overloaded issues.
AI meant using Supabase just for authentication, handling user accounts, logins, and storing that auth related data in Supabase.
Then I’d use D1 for everything else in my app, like user posts, comments, and other application data.
I was mainly wondering if that’s the right way to use D1, or if most people use it differently?
As you pointed out, D1 might not be ideal for storing auth/session details directly, so I figured Supabase could handle that part while D1 just handles the rest of the app data.
Then I’d use D1 for everything else in my app, like user posts, comments, and other application data.
I was mainly wondering if that’s the right way to use D1, or if most people use it differently?
As you pointed out, D1 might not be ideal for storing auth/session details directly, so I figured Supabase could handle that part while D1 just handles the rest of the app data.
LSame thinking applies. A single D1 database has certain capabilities, like 128MB memory and can process a few hundred queries per second depending on query complexity. For indexed SELECT queries you can get around 1K/second, but usually if you mix with writes my rough guideline is 300-800/second. And of course the hard limit of 10GB (you should try to stay lower than that though).
So, if you plan on having thousands of users active at the same time you will need to use several D1 DBs.
If you are going to need more than a few tens DBs to handle your traffic, SQLite Durable Objects might fit your use-case better since you can create DBs dynamically in your code and the underlying SQLite engine is exactly the same.
So, if you plan on having thousands of users active at the same time you will need to use several D1 DBs.
If you are going to need more than a few tens DBs to handle your traffic, SQLite Durable Objects might fit your use-case better since you can create DBs dynamically in your code and the underlying SQLite engine is exactly the same.
Knpx wrangler d1 migrations create DB init
LThank you
J@Visal .In UI Bug: I am seeing mac keys on my windows computer
VWill fix it 
JWould also be cool if we could save queries like you can with supabase
Dmaybe im just silly, but does the d1 jurisdiction affect anything legally?
HSure, if you are handling EU customer data under the GDPR, you can keep that data within the EU
HThough I would ask an advisor to whether that is necessary for your specific case
Lguys, is there something like "migrations" (schemas which will automatically applied when a worker is deployed)?
I'm fairly new to D1 but I have worked with durable objects before.
I'm fairly new to D1 but I have worked with durable objects before.
ILah, thx 
LI mentioned it before but just to point out that this the built-in way of doing things, but not the only way. You could literally use a similar flow as to what you were doing with DOs, but instead of running the queries in the local SQLite you would run them in the remote D1 DB.
LI got another question. Since D1 uses SQlite dialect, can I store a column of type
TIMESTAMPbecause if not, I gotta store ISO timestamps in text format
Luuuh, what?
LSee https://developers.cloudflare.com/d1/worker-api/#type-conversion for details on some types specific gotchas as well.
Supported SQLite types are in https://www.sqlite.org/datatype3.html (I don't see TIMESTAMP)
Supported SQLite types are in https://www.sqlite.org/datatype3.html (I don't see TIMESTAMP)
IThey mean that D1 actually runs SQLite itself, it's not a custom SQLite compatible engine.
Lah
Lmakes sense
LI'm storing as iso timestamps now 
Ddoes the replication when enabled actually show any metrics for it, I have it turned on, can see the X-D1-Bookmark: responce header etc but there seems to be no metrics in the D1 Ui, the dropbox also says eplicas 0 ?
1d1 jurisdiction is huge
1and it maintains replicas within the jurisdiction which is also huge
1???? only happens on the jurisdiction table not sure why its throwing a r2 bucket error lol
1recreated a bunch of databases and this error only occurs for jurisdiction created databases, not for normal location hint creations both in the same EEUR region
FI have been able to reproduce it on my end. I'm forwarding it internally.
LYou will see metrics for each region serving queries, yes. But, replicas are used only on-demand for queries inside each region, they don't run all the time. For example, if you have traffic in ENAM and EEUR, you should see the primary and the replicas in those two regions being in your metrics.
Sis d1 down?
Smy workers endpoints using it take forever to load
Salso I cannot use cloudflare's endpoints to make changes externally
S504, {"result":null,"success":false,"errors":[{"code":7009,"message":"Upstream service unavailable"}],"messages":[]}
Skeep getting these
LThe fix for this should be out now everywhere. Thank you for reporting.
J@Visal .In not sure if you are the correct one to ping, but I am having really bad D1 performance. I have a simple query
where
where
token_hash64,360Scratch that. was a bad index I had taking up too much index space
AIs d1 suitable for web apps with say thousands of daily users? It feels complicated to setup multiple d1s so I would prefer to just have like one for all users like a ”normal” database
AI'm using it for this, just keep in mind it's single threaded so there are limits to scalability. But I'm using replication and it's working great since enabling that for my few thousand users.
AOh okay, could you point me to guides or docs on how to achieve this? Also how well does this structure handle many writes and limits of like 10gb storage or the 128mb memory limit?
BHi I don't know if this is known but maybe someone from Cloudflare decides to push on this. Sadly because cloudflare uses PRAGMA defer_foreign_keys not the simple turn on or off the migrations generated by drizzle are invalid and often broken. This means if we want to use drizzle with cloudflare we need to hand edit migrations
LI am hoping to merge this docs update on Monday, and it contains some guidance on D1 performance: https://github.com/cloudflare/cloudflare-docs/pull/26369
If you have thousands of active users at the same time, which will translate to high hundreds or thousands of queries to D1 at the same time (e.g. per second), then you will hit performance limitations and overload the single database.
You will definitely need to shard across several databases.
If you are going to have many thousands of queries per second and would need tens of D1 DBs, then using SQLite Durable Objects would be preferable and my suggestion. You can create thousands of Durable Objects dynamically in your code without having to mess with bindings, and it's the same underlying SQLite engine.
If you have thousands of active users at the same time, which will translate to high hundreds or thousands of queries to D1 at the same time (e.g. per second), then you will hit performance limitations and overload the single database.
You will definitely need to shard across several databases.
If you are going to have many thousands of queries per second and would need tens of D1 DBs, then using SQLite Durable Objects would be preferable and my suggestion. You can create thousands of Durable Objects dynamically in your code without having to mess with bindings, and it's the same underlying SQLite engine.
TBefore I test, how many rows per second can D1 / DO with SQL scan per second? any unofficial data around it?
LI have seen high hundreds of thousands or single digit millions reads per second. Obviously it's different if your rows are 10 bytes vs 2MB!
Also, with such high number of reads per second, if you are doing that constantly you need to be careful of hitting CPU limits, or overload limits since a DO is single threaded.
Also, with such high number of reads per second, if you are doing that constantly you need to be careful of hitting CPU limits, or overload limits since a DO is single threaded.
CHi, I have a question about D1. I'm using it together with Drizzle ORM. I have a table that stores user balances, and each request deducts from the balance. The issue is that a simple query like
amount -= 100