are there any case stuides/examples of cloudflare customers that have thousands of dbs? Curious what its like to actually have to manage that many databases in production.
Really cool. I like the simplicity of using an explicitly provided "shard/hash key". It makes the routing much simpler. This is similar approach to how I shard across SQLite DOs.
I wonder how this was developed, was it a work project, college project (hint in the name), or just a side project? Majority of the logic seems to have been added in a single commit.
Either way, very nice to read through. Haven't checked the code yet. This is not an endorsement to use this in production, BTW.
Unfortunately, I am not aware of publicly documented cases. We do have a few users that are like agencies developing apps for other companies and use thousands of D1 DBs. They mostly manage them through the REST API. Most of these cases are not attaching thousands of DBs to a single worker, as far as I know, although some did and use the Workers Patch API to update the bindings on their worker dynamically.
My suggestion, if you have a single worker project and want thousands of DBs using SQLite DOs will give you a much nicer experience. Now, if you are a platform creating thousands of projects and each one needs a small D1 DB that's a great use-case for D1 and managing the DBs through the API.
We are building a db per customer architecture and were holding out for dynamic bindings. However decided to bite the bullet and currently migrating from d1 to durable objects. Was initially reluctant but have to say it gives you a lot more flexibility and as a bonus has opened up some nice opportunities for performance optimisations.
yeah, just plain jane sqlite, but only accessible via the DO runtime, no backdoor, file based access. Treat the DO as a web server running in the same process as the sqlite process and you're only way to run bindings/sql console. Which it literally just is that.
no, but some people get the impression DO sqlite is something they get more 'native' sqlite access to the file system or extensions if they don't know otherwise
Each database is backed by a Durable Object, which is single threaded SQLite under the hood, so the limit depends on how fast/slow your queries are. If your queries execute at 1ms, you can do 1K of them at most, etc. Rough guideline is that for most cases we see SELECTs with proper indexes usually finish in less than 1ms, and writes are a few milliseconds, so depends on your case. My ballpark generic guideline is about 300-900 queries per second.
We have users doing more, and we have users doing less.
great thanks. ok I didn't realize D1 uses Durable objects... I really need to understand DO b/c I'm a little confused now I thought DO were backed by sqlite, but didn't realize d1 has DO "in front" of it.
Architecturally would it be possible to implement Cap'n Proto as a data type for D1? Spanner recently released protocol buffer support (apparently was available for years in their internal build) and it unlocks some really cool features like type safety and 10x faster performance vs storing nested data in JSON/JSONB. Compared to Spanner's approach, Cap'n Proto seems like it would be significantly better too since it's zero-copy. Is this something that's been considered or technically feasible with D1's architecture?
D1 is a more managed database over using SQLite Durable Objects directly, so it's great when you can shard your application data model across several of them. Sweet spot is a few tens so not exactly per user but not limited by the 10GB limit either, if you need more than that in the thousands you are better to use DOs directly.
Imagine apps like the trendy vibe coding platforms nowadays where you need a database for millions of independent projects and each one is self-contained and small, just as an example where it fits great. Or internal projects that fit within 10GB (or N multiples of them where sharding comes naturally) and the traffic is not crazy.
Well, social media is broad. If you are building Facebook, no. If you are building your own version of a small social media platform you could involve D1 in certain aspects for sure, e.g. for things that are private to a user. But then it also depends no usage, so just by a 2-word description it's not obvious. Again, my guideline rule is that if you are fine with 0-100GB of total storage and requests are not tens of thousands per second, D1 can work. Otherwise, if sharding is natural to your app, SQLite DOs, otherwise Hyperdrive + any external traditional database.
Did something change in how Cloudflare is calculating D1 DB size. All of the sudden all databases are half of the size that they were in the past. Any insights into what is happening? Thank you
Which API exactly? I checked your known accounts and don't see any drop in total size from our analytics. Please DM me more details instead of publicly here.