I could handle that at the application layer for a fixed number of databases but you end up predefin

I could handle that at the application layer for a fixed number of databases but you end up predefining a fixed set of databases in a wrangler config file and then accessing them in your workers. Feels strange and hard to scale. Is there a better way?

Right now, I have everything in one DB. I'd probably shard by customer account for simplicity and replicate schemas across instances. I could of course split my data in other ways but this feels the most flexible at the moment.

TTait I could handle that at the application layer for a fixed number of databases but...

1984 Ford Laser•3/26/25, 3:30 AM

Right now Durable Objects with SQLite with the way to scale in this way, but dynamic D1 bindings are in the pipeline somewhere, coming :soontm:

Aajgeiss0702 cloudflare has said in the past that dynamic bindings for things like D1 are a g...

Jake•3/26/25, 9:33 AM

Do you have a link for info on developer week? I can’t find anything about it.

TTait I could handle that at the application layer for a fixed number of databases but...

lambrospetrou•3/26/25, 10:59 AM

You can patch the Worker config through the REST API when you create a new database instead of having to put them manually in wrangler. It's a pain though since you need a bit of custom code on your side to do that. If you really want to handle thousands of databases, I would say that Durable Objects SQLite are much more suitable at the moment. The 1GB limit it only until it goes GA, soon.

Ddivineflu question: why does the hard limit of 10gb exist for d1 ? even if its database p...

lambrospetrou•3/26/25, 11:03 AM

D1 databases are based on SQLite Durable Objects. If a Durable Object SQLite database could grow to 1TB then cold starts would be prohibitively slow. We could do lazy loading and all that jazz, but then you lose the super fast performance of local SQLite queries. 1-10GB is a good-enough size to enable many use-cases and OK cold starts.

TaitOP•3/26/25, 11:03 AM

I'm thinking about living with my single 10G DB and hoping something changes with the cloudflare offering in the next 6 months. Either dynamic binding to databases in wrangler / workers or a larger single DB limit. If Durable Objects + SQLite were the future of scaling SQLite in the cloudflare stack I could start experimenting with that now but without an knowing that's the case I'd probably sit on my hands.

TTait I'm thinking about living with my single 10G DB and hoping something changes wit...

lambrospetrou•3/26/25, 11:04 AM

Individual DBs will not grow larger anytime soon, at least not any plans currently.

Llambrospetrou D1 databases are based on SQLite Durable Objects. If a Durable Object SQLite dat...

TaitOP•3/26/25, 11:07 AM

Thanks for the perspective on that! I can live with a 10GB database for the near term. I'll just need to figure out a plan to shard data should my application be successful and grow (or move to a new provider). I'm sure I'm not the only one. The more developer content that gets produced about scaling D1 or Durable Objects + SQLite the more retention you guys will drive. If I missed something LMK.

TTait Thanks for the perspective on that! I can live with a 10GB database for the ne...

lambrospetrou•3/26/25, 11:10 AM

Durable Objects can scale to great extend, as long as you design for sharding from the get go. It takes a bit of a mindshift since all traditional tutorials and online content is focused on big monolithic databases. Depending on the application doing sharding could be easier or harder, so it really depends how far you want to go.
The blog posts in this section https://developers.cloudflare.com/durable-objects/what-are-durable-objects/#durable-objects-in-cloudflare describe how we use DOs in several products, so that you get some idea of how to think with them.

At the end of the day, if you don't want or cannot think in terms of sharding, Hyperdrive is an awesome approach too, so just use that with your traditional database provider. Different tradeoffs in each approach.

TaitOP•3/26/25, 11:16 AM

I was planning on just sharding by customer account. For my application, I'd be shocked if customers get more than 1G of data. That's just an easy starting place. ALL DB instances look the same.

For hyperdrive, my stack right now is hono + drizzeORM + cloudflare workers with D1 and R2. I'd have to look at how to work. hyperdrive into it and how much of a rewrite that owuld be.

o7•3/26/25, 11:20 AM

Will D1 Dynamic Bindings essentially be a wrapper around SQLite for DO? Or will it have extra bells and whistles like tooling with the same performance as SQLite for DOs, or same as current performance. (performance as in latencies)

VVisal .In You can also try Durable Object SQLite storage. According to docs, you can creat...

divineflu•3/26/25, 11:30 AM

thanks. this is useful info

Llambrospetrou D1 databases are based on SQLite Durable Objects. If a Durable Object SQLite dat...

divineflu•3/26/25, 11:32 AM

going to deploy a single db on d1 for now
if it gets out of hand, i guess turso is the next stop

Oo7 Will D1 Dynamic Bindings essentially be a wrapper around SQLite for DO? Or will ...

lambrospetrou•3/26/25, 11:47 AM

The SQL query performance itself is identical between D1 and SQLite DOs. The only difference is that D1 is in a different location from your Worker code location so doing multiple D1 roundtrips can be costly depending on those locations. With DOs you could colocate code inside the DO and then you always have fast access. If you are calling your DO from a different worker for each query then performance is again identical between the two products.

D1 REST API is completely separately flow, and should not be used in hot paths of your application on Workers.

Llambrospetrou The SQL query performance itself is identical between D1 and SQLite DOs. The onl...

o7•3/26/25, 12:02 PM

Thank you. Best performance will always come directly from a Durable Object with the SQL backed storage - I'm still pondering on building around it.

The only thing left to wonder is what kind of management tooling D1 dynamic bindings will have? (bulk DB deletion, reading/modifying multiple DBs, listing DBs?)

Oo7 Thank you. Best performance will always come directly from a Durable Object with...

lambrospetrou•3/26/25, 12:31 PM

I wouldn't design my architecture based on future features. Maybe Dynamic Bindings come with those niceties you mention, and maybe they come to DOs as well, or maybe it's going to be very different.
If you want to ship your app now, I suggest thinking with the existing tradeoffs.

Llambrospetrou I wouldn't design my architecture based on future features. Maybe Dynamic Bindin...

o7•3/26/25, 12:32 PM

I guess i can always migrate. Thanks again!

JJake Do you have a link for info on developer week? I can’t find anything about it.

ajgeiss0702•3/26/25, 4:04 PM

https://www.cloudflare.com/developer-week/
it still has last years' articles up, they usually update it to the current year a few days before it starts iirc

Developer Week 2024 | Cloudflare

Cloudflare Developer Week April 1-5, our week-long series of new product announcements and events dedicated to enhancing the developer experience to fuel productivity!

crossbeau•3/26/25, 11:21 PM

Is there a cost different on sqllite in do vs using d1 and any other limiting factors?

crossbeau•3/26/25, 11:23 PM

Im working on building a discord bot, with d1 as a backend, but considering speed is important with an interactive bot kind of tempted to switch. Especially as all commands come from minimally changing Data centers

Ccrossbeau Is there a cost different on sqllite in do vs using d1 and any other limiting fa...

Isaac McFadyen•3/27/25, 12:24 AM

SQLite in DO is limited to 1GB per instantiated DO at the moment.

Isaac McFadyen•3/27/25, 12:25 AM

That limit should increase to 10GB (same as D1) once it's out of beta, though.

Ccrossbeau Im working on building a discord bot, with d1 as a backend, but considering spee...

James•3/27/25, 4:15 AM

You pay wall time on DO. And expensive computations in sql will cost you cpu time plus R/W in DO. The upside is you can do fancy stored procedure type app logic on the same thread as your DB with DO.

Florencia•3/27/25, 12:08 PM

@Isaac McFadyen

Ccrossbeau Is there a cost different on sqllite in do vs using d1 and any other limiting fa...

John Spurlock•3/27/25, 3:19 PM

you've probably already considered this, but on the cost side: after you've burned through the free tier, D1 storage is also 3.75x more expensive than SQLite in DO

Sébastien Morel•3/27/25, 5:48 PM

hello, is there something going on ?

Screenshot_2025-03-27_at_10.48.06_AM.png

SSébastien Morel hello, is there something going on ?

lambrospetrou•3/27/25, 7:32 PM

There isn't anything service wide. What queries are you doing? That seems like a scan to me. You already have weird spikes before for queries taking 500ms.

Sébastien Morel•3/27/25, 9:11 PM

hey @lambrospetrou thx for this, I am investigating, it went down already but that's odd it's like 4.5 sec !

xeon06•3/29/25, 8:19 PM

Is it possible to create a read only endpoint for D1? For dashboard stats and such for instance. It looks like via the rest API I could possibly just use a

D1 Read

D1 Read

token API token and then any writes would fail? Doesn't seem like there's a way to do this through workers API

Xxeon06 Is it possible to create a read only endpoint for D1? For dashboard stats and su...

Hello, I’m Allie!•3/29/25, 8:47 PM

You could just expose a Worker with some pre-determined routes that only ever perform selects?

xeon06•3/30/25, 4:14 AM

I want the queries to be driven by the UI à la BI tools like Periscope and Tableau

Marcel Overdijk•3/31/25, 3:04 PM

As per docs D1 has TypeScript support for representing rows like:

// Row definition
type OrderRow = {
  Id: string;
  CustomerName: string;
  OrderDate: number;
};

// Elsewhere in your application
const result = await env.MY_DB.prepare(
  "SELECT Id, CustomerName, OrderDate FROM [Order] ORDER BY ShippedDate DESC LIMIT 100",
).run<OrderRow>();

// Row definition
type OrderRow = {
  Id: string;
  CustomerName: string;
  OrderDate: number;
};

// Elsewhere in your application
const result = await env.MY_DB.prepare(
  "SELECT Id, CustomerName, OrderDate FROM [Order] ORDER BY ShippedDate DESC LIMIT 100",
).run<OrderRow>();

What if the database has snake case column names, but I want to keep camel case;
is there a simple (automatic) to convert his?

e.g. like Drizzle supports with

const db = drizzle({ connection: process.env.DATABASE_URL, casing: 'snake_case' })

const db = drizzle({ connection: process.env.DATABASE_URL, casing: 'snake_case' })

If not wouldn't that a nice feature request?

Marcel Overdijk•3/31/25, 3:04 PM

(I'm trying to avoid writing a lot of mappers)

Marcel Overdijk•3/31/25, 3:05 PM

or maybe best to use something like https://www.npmjs.com/package/camelcase-keys ?

MMarcel Overdijk As per docs D1 has TypeScript support for representing rows like: ``` // Row de...

lambrospetrou•3/31/25, 3:27 PM

No, out of the box we don't do that name conversion for you with the current D1 binding.

Llambrospetrou No, out of the box we don't do that name conversion for you with the current D1 ...

Marcel Overdijk•3/31/25, 4:51 PM

Is it worth a feature request? (like the Drizzle example)

Burrito•3/31/25, 4:55 PM

This is probably something better done in user land.

Nicolasmp•3/31/25, 7:48 PM

Hi folks! We are looking to use D1 for a multi tenant application. We are looking to ways to keep d1 databases isolated at a tenant level. Right now the only limitation I see is that bindings are static, is there any way to dynamically bind to my d1 instances? Or any other recommendation on how to achieve this?

MMarcel Overdijk Is it worth a feature request? (like the Drizzle example)

Isaac McFadyen•3/31/25, 8:30 PM

Probably not, D1 is SQLite and SQLite doesn't perform any inspection of the query itself because it's intended as a raw SQL executor. Adding this behavior would require adding non-standard parsing in front of SQLite.

Original message was deleted

xeon06•4/1/25, 1:36 AM

It's what all these BI tools let you do

gruntlord6•4/1/25, 2:42 AM

Is there a place I can accuratly see how many reads/writes I have done in a billing period? The billing section says I have done 0 which is very much not true, although if you want to leave it that way for calculating billing I'm ok with it

Xxeon06 It's what all these BI tools let you do

sathoro•4/1/25, 3:45 AM

no, they don't. they generate SQL from sanitized user input, they don't use raw input as the query

Vlady•4/1/25, 3:42 PM

Hey folks, what is D1's current limit for requests per second for paid accounts? I found this response but not sure if it applies. d1-database

Vlady•4/1/25, 3:44 PM

I'm working on a ticket service with high surge potential and I need to let my customers know.

VVlady Hey folks, what is D1's current limit for requests per second for paid accounts?...

Isaac McFadyen•4/1/25, 3:45 PM

That applies, yup.

Isaac McFadyen•4/1/25, 3:45 PM

If you need more performance/capacity you'll need to shard across multiple DBs.

mr.niko.la•4/2/25, 3:16 PM

is there a recommenday way to get better ux on the d1. new to cf and sqlite. the webgui is very basic. is there any recomendation?

do i just get local replicate and even then what is a good viewer for the db

Mmr.niko.la is there a recommenday way to get better ux on the d1. new to cf and sqlite. t...

lambrospetrou•4/2/25, 3:22 PM

You can use https://www.outerbase.com/blog/now-supporting-cloudflare-d1/ although I haven't personally tested it, but saw happy users before.

Llambrospetrou You can use https://www.outerbase.com/blog/now-supporting-cloudflare-d1/ althoug...

mr.niko.la•4/2/25, 3:40 PM

not bad was very easy to setup and much better ux. should be ok for now thx.

Silvan•4/2/25, 3:59 PM

am i the only one that just sqlite3s the db file inside .wrangler?

// Row definition type OrderRow = { Id: string; CustomerName: string; OrderDate: number; }; // Elsewhere in your application const result = await env.MY_DB.prepare( "SELECT Id, CustomerName, OrderDate FROM [Order] ORDER BY ShippedDate DESC LIMIT 100", ).run<OrderRow>();

I could handle that at the application layer for a fixed number of databases but you end up predefin

Similar Threads

Similar Threads

Similar Threads