> Maybe more precise replica configs could help that too. For the sake of brainstorming, if you have

Maybe more precise replica configs could help that too.

For the sake of brainstorming, if you have low traffic, say 1 request every 15 minutes from some regions, how would a replica config help? How do you imagine it behaving from your side?

Llambrospetrou > Maybe more precise replica configs could help that too. For the sake of brains...

Chaika•4/14/25, 4:52 PM

I meant that more in the case of: Having lots of traffic in ENAM/EEUR (so replicas in both, kept warm/active), and being able to disable Oceanic and Asia Pacific replica regions so infrequent requests from those regions don't incur the currently quite large 4-5 seconds of cold start latency over and over

CChaika I meant that more in the case of: Having lots of traffic in ENAM/EEUR (so replic...

lambrospetrouOP•4/14/25, 4:54 PM

Ah yes, this makes sense.

Chaika•4/14/25, 4:54 PM

Although I suppose the other way to solve that would be to lower the cold start time in those far away regions from your primary, not sure what would be involved for that though

Zack•4/14/25, 5:14 PM

I mean, would another option to be able to pay an extra fee for "always-on" replicas?

Zack•4/14/25, 5:15 PM

Doing rough maths, replicas are essentially a durable object, keeping a durable object online for an entire month would normally cost just over $4 with duration costs

Zack•4/14/25, 5:16 PM

Obviously reducing replica cold start time is the preference so that isn't necessary, but maybe for people who don't want to deal with that at all, having an "always-on" option would be something that could be considered

ZZack I mean, would another option to be able to pay an extra fee for "always-on" repl...

lambrospetrouOP•4/14/25, 5:45 PM

You can do this easily already by having a DO doing

select 1;

select 1;

from each region with an alarm every 1 minute if you really want, but at this point there isn't much gained from using a replica. Is that single request every few minutes that important that you cannot go to the primary for an extra 100-200ms? We need to provide a way to skip replicas and go straight to the primary though to avoid the replica booting up.

Llambrospetrou You can do this easily already by having a DO doing `select 1;` from each region...

Zack•4/14/25, 5:45 PM

Depends how quickly those instances shutdown, but if you're on the other side of the world to the primary, probably, yes

Zack•4/14/25, 5:46 PM

I did consider doing the SELECT 1 to keep it warm, but obviously something official would be nicer. Surprised you guys are suggesting something like that publicly

Zack•4/14/25, 5:47 PM

I'll be giving it another go once these fixes are in for the issues last week, maybe after that it won't be necessary anyway

Zack•4/14/25, 5:54 PM

It also depends on your traffic patterns, for us for example, we have lower traffic in APAC and OC, especially overnight, but when those requests do come through it can be anywhere between 10 or 100's of requests

Zack•4/14/25, 5:54 PM

For those regions it probably takes >1 second to get to the primary

Zack•4/14/25, 5:55 PM

FWIW though we don't currently see problematic behaviour wrt this on our existing databases, which are one per region

Zack•4/14/25, 5:57 PM

I don't know if you can share this, but do the replicas have to go back to the primary storage in the primary region to retrieve the database when cold starting? Or are some checkpoints stored local to that region, so that it only has to sync what has changed since last time via the WAL?

ZZack I did consider doing the SELECT 1 to keep it warm, but obviously something offic...

lambrospetrouOP•4/14/25, 6:36 PM

I am NOT suggesting it. I said you can do it already if that's what you want.

Llambrospetrou I am NOT suggesting it. I said you can do it already if that's what you want.

Zack•4/14/25, 6:36 PM

I more meant even saying it publicly

ZZack I more meant even saying it publicly 🤣

lambrospetrouOP•4/14/25, 6:37 PM

I mean, you pay for it.

Zack•4/14/25, 6:37 PM

Sure, reads are essentially free though

Zack•4/14/25, 6:38 PM

I guess if you do it from DOs you're paying for keeping those alive

Matthew•4/14/25, 9:44 PM

Hey, has anybody done any measurement/comparison between D1 and Hyperdrive performance wise? I'd like to migrate from D1 to Hyperdrive and would love to know more beforehand.
Thanks Xx

MMatthew Hey, has anybody done any measurement/comparison between D1 and Hyperdrive perfo...

lambrospetrouOP•4/14/25, 9:46 PM

Without specifying your workload (volume + kind of queries), location of source and target, and latency needs, no benchmark would really make sense for you.

Llambrospetrou Without specifying your workload (volume + kind of queries), location of source ...

Matthew•4/14/25, 9:47 PM

I see, you're right. But it would generally help if we knew which one would be better for what type of use cases..

Llambrospetrou Without specifying your workload (volume + kind of queries), location of source ...

lambrospetrouOP•4/14/25, 9:48 PM

For example, if all your users are in EEUR/WEUR, and you use Hyperdrive with a Postgres database on a 4GB host in Frankfurt, that's probably going to perform amazingly well, and probably better than a single D1 database.
If you use tens of D1 databases spread around close to each of your user, and you have traffic from everywhere, then the comparion is more nuanced.

jed•4/15/25, 3:00 AM

is there a performance penalty for using D1 via the REST API from a worker, as opposed to using the Workers Binding API? or is the binding just a wrapper around the REST API?

Jjed is there a performance penalty for using D1 via the REST API from a worker, as o...

Cyb3r-Jak3•4/15/25, 3:04 AM

Yes. All requests have to go back to Cloudflare's core, so request latency is far from optimal from some locations. You would also be subject to the API Rate limit of 1200 requests per 5 minutes.

CCyb3r-Jak3 Yes. All requests have to go back to Cloudflare's core, so request latency is fa...

jed•4/15/25, 3:05 AM

awesome, thank you!

Jjed is there a performance penalty for using D1 via the REST API from a worker, as o...

lambrospetrouOP•4/15/25, 7:33 AM

Yes, at the moment we don't really recommend using the REST API as part of the hot path of your application.
We are working on making that path faster this quarter, but using the D1 Binding through a worker will always be the fastest since you are going directly to your database.

IIsaac McFadyen Correct on both accounts, yeah. Hopefully in the future there will be a workarou...

_Ultima_•4/15/25, 10:16 AM

So for now, bind e.g. 100 D1 instances manually to a worker and use KV to make sure the tenant is connecting to the correct D1 instance. (making sure the tenants are spread equally across the D1 instances)

FFlikTeoh I'm actually doing select 1 on every page load that uses d1 though 😬 helps to r...

Zack•4/15/25, 11:32 AM

I have considered doing this even for cached requests, just to keep things warm. Around 60% of our requests that would otherwise invoke the database are cache hits, including the other requests too, it's more like 85%

Zack•4/15/25, 11:32 AM

So could quite easily just do SELECT 1 everywhere and have a much warmer database

Zack•4/15/25, 11:33 AM

I don't like hacks like this though, so hopefully replication improves after this round of bug fixes and the ongoing improvements through the open beta period

FFlikTeoh Yeah thats what I was hoping to see from the replication. But still even with th...

lambrospetrouOP•4/15/25, 12:11 PM

same d1 could sometimes be in the 180ms range, or the 500ms range

Is this variance for the same query, from the same worker in the same location, for the same database?
Is this with or without replication?

FFlikTeoh Without replication, everything else is the same. Could be 180ms this hour, then...

lambrospetrouOP•4/15/25, 12:16 PM

Is it consistent for those periods though? Will it be mostly 180-200ms this hour, and 480-500ms 2 hours later, or do you see variance regardless?
If you are using the Workers binding, and your workers are roughly from the same location, then latency should be quite similar.

FFlikTeoh I haven’t keep track of the hours but I do notice sometimes it’s in 180-200ms ra...

lambrospetrouOP•4/15/25, 12:23 PM

If the locations of the caller are different the latency will be different too. Anyway, if you have more concrete data, we can revisit.

FFlikTeoh Oh and sorry. I did turn on replication in the dashboard but have not yet implem...

lambrospetrouOP•4/15/25, 12:24 PM

If you have replication enabled, even if you don't use the sessions API your queries will flow through replicas and forwarded to the primary. So, the performance could be different than when you were going straight to the single primary. Again, depending on your caller's location.

FFlikTeoh This is still a project under development. So basically I was the only person ac...

1984 Ford Laser•4/15/25, 9:40 PM

What colo are your requests being served from, and is that your closest location?

FFlikTeoh It says APAC, and yes that should be the closest location

lambrospetrouOP•4/16/25, 9:23 AM

APAC unfortunately is our worst region in terms of consistent latency. It spans quite large distances: https://where.durableobjects.live/region/apac
So, if your database moved from one location to another for any reason (e.g. datacenter downtime, network issues) then your latency could be impacted in large ways. That would be my guess what's going on, but without concrete data and timeranges I cannot say much else.

_Ultima_•4/16/25, 11:59 AM

Question, if i bind 100 D1 servers to a worker and use KV to target a specific one. (lets say i run 1 query on 1 specific D1), what would the billing look like? Do the other 99 D1's cost anything? (for now empty)

__Ultima_Question, if i bind 100 D1 servers to a worker and use KV to target a specific o...

lambrospetrouOP•4/16/25, 1:05 PM

No, you only pay for rows read and written, and your storage used. https://developers.cloudflare.com/d1/platform/pricing/

Note: empty databases still consume tiny bit of storage for SQLite metadata (few KBs), although for your 100 DBs it's negligible.

parisholley•4/17/25, 1:30 AM

can someone clarify what "region" means with replicas? is a single datacenter being chosen within a region (balanced across customers presumably with some internal algorithm) to host the replica, or is the replica always going to be on the nearest datacenter (pop) to the user?

Pparisholley can someone clarify what "region" means with replicas? is a single datacenter be...

lambrospetrouOP•4/17/25, 9:16 AM

The heuristic and algorithm for replica placement is ongoing and will change over time.
The current placement is that it picks a random location within each region and all requests originating from that region will go to that replica. The usual availability applies for replicas too, if the datacenter does down, it will move somewhere else in the same region until the original datacenter comes back online.

This will change down the line, though, and become smarter. We explore several heuristics at the moment how it would look like.

> Maybe more precise replica configs could help that too. For the sake of brainstorming, if you have

Similar Threads

Similar Threads

Similar Threads