Also keep in mind that the first 25 billion reads are included in the basic paid plan, so you could refresh the dash 271 million times a month and be OK
Thank you very much. One last question: Since we are migrating our python scripts from mongodb to D1 is there any way to mass insert rows from an external script using the api, outside of workers?
Is 2GB per table very much? I've never really built anything at a scale of more than 1k users so I have no idea.
My best comparision metric right now is a CSV that I have with 82 columns and 101k rows listing every single K12 school in america. That CSV is 46MB, and the Google Sheets version is apparently 16MB
All depends how much data you want to save. I have 8 users and around 3GB in the database. It will be higher limit in the future but also already supports alot of DBs so you could setup one per user (soon)
Hmm I guess that's a relatively smart way to shard things, especially if a user is almost always in a defined location.
E.g. if I was creating software to manage parking garages or movie theaters, it could make sense to have 1DB per theater, and 1DB for the "central office" objects that might need to be referenced for all of the DBs
But it still sounds crazy and seems like it might increase the total # of writes?
If I knew what I was doing, I would agree with this sentiment. But I'm a novice at building product-caliber stuff, so I don't know where to begin other than I want it to be simple to deploy and not eat more than like $10k/yr at scale with a million users in the year.
At smaller scales, I want my whole app to cost < $1/user/mo
Basically, I'm building a course app. We teach high schoolers how to build real products such as Wildfire Simulator in Unity or a Webapp. (I already sell my product to school districts, but am trying to build some in-house custom features and better reporting compared to the third-party tools we're currently using, and then also enable some AI tutoring features in the future).
We host videos, interactive exercises, and quizzes basically. It's kind of like a Masterclass + Brilliant.org
We also have a couple of interesting real-time features such as an office hours queue (so as students are going through one of our projects they can ask a question, and then we group similar questions together and answer the group on a live video call).
Would love to design the system right such that we don't have to completely redo stuff in the near future.
estimate how big your database needs to be (define your schema and ask chatgpt how large the db would be with x rows in each table) if you’re comfortably under 2gb go with d1
ok so if I want to track users' progress through sections of a course (and let's say a course has 50 sections) there would be ~50 rows per user in the user progress table.
Does that mean I'm actually limited to something like 2GB * (1 progress row / 1MB) * (1 user / 50 progress rows) = 2 million / 50 = 40,000 users?
What Matteo said. Increment a counter. Store a “last chapter” variable. I wouldn’t store a “row per event” in any database as it makes your queries far more complex.
yea something like that. I think there's a field for manual checkoff or something as well, but you're right that join table doesn't seem like it should be that complicated
so the way it gets somewhat complicated is that we count a person's progress as done if they've met the criteria which would be to get certain quiz questions right and at least submit a certain set of quiz questions (graded for completion) or if they have a manual check off. But I guess my worker should be calculating that per user and not storing that result in the table?
Data structure is a pain to figure out, you might also consider storing a JSON column with the answers... and a column with the calculation result, no need to redo it for a single boolean column.
Yea, we've been using Coda (similar to Notion but with much more powerful tables and APIs) to prototype this thing. Working surprisingly well with our group of <100 users. So some of the columns in Coda are just there for calculations and probably wouldn't need to be there in a real SQL table thanks to joins and having code on front or backend that would do the calculations
I couldnt find any docs/tutorials related to create a d1 database programmatically for the same worker. I wonder if I can keep same binding name for all the database that I create for the same worker.
How does the migrations work for those databases ?
Manually running command to apply migrations will take a lot of time.
Hi, quick question, does D1 require connection pooling? I'm using Next.js for a project and it doesn't support singletons for the purpose of supporting serverless, and all of its docs point to connecting to the DB when a request is received, but will that be a problem with D1?