Some more feedback: I reverted back to our original setup after a few hours, though we saw no errors

Some more feedback: I reverted back to our original setup after a few hours, though we saw no errors, latencies did increase more than I would have liked. Note that these graph quantiles aren't accurate for their quantile due to the way the metrics are currently aggregated, but the difference between the before and after is accurate and does show a significant shift in our latencies

ZackOP•4/26/25, 7:37 PM

However we experienced zero errors whatsoever, so that is a significant improvement from before!

ZackOP•4/26/25, 7:38 PM

I think I asked this question before, but I don't think it was answered. For the replicas, when they startup, do they have to go back to the origin DC for all of the data they need, or just for any recent checkpoints they are missing? I ask this because I think the reason we are getting these latency spikes is for regions where it was currently nighttime and the requests were low

ZackOP•4/26/25, 7:39 PM

I think for APAC for example, the latency can spike substantially if the replica is currently shutdown as it needs to fetch the data from the source in WEUR

ZackOP•4/26/25, 7:40 PM

However, if this data was cached near the replica location so it only had to go back "home" for new checkpoints, then I would expect this to not have much impact, especially for our database as it is entirely static, we never insert new rows

ZZack Some more feedback: I reverted back to our original setup after a few hours, tho...

lambrospetrou•4/27/25, 8:02 AM

but the difference between the before and after is accurate and does show a significant shift in our latencies

Where is the difference in this graph? Can you post that instead of the percentiles that you say are wrong? What is the magnitude of the difference you see, 1s, 5s, 500ms?

ZZack I think I asked this question before, but I don't think it was answered. For the...

lambrospetrou•4/27/25, 8:06 AM

The snapshot to boot a replica initially is fetched from the primary's region as far as I remember, but will double check and confirm. Then, once the replica is caught up, updates flow from the primary to all replicas in parallel while they are written to the primary. This should still only add a few hundred ms delay vs if it was in the replica's region, not multiple seconds, unless networking is really bad in those regions (APAC is quite noisy).

Either way, this case is already something we are working on improving/fixing soon, so that you don't need to wait for replicas to boot and they are used only once they are booted. So, these spikes should be eliminated.

Llambrospetrou > but the difference between the before and after is accurate and does show a si...

ZackOP•4/27/25, 8:15 AM

I can try to get some proper numbers on that, I did break it down by Colo and see some significant spikes. I do have metrics specifically for the D1 call so I can look at pulling those out and getting something useful for you guys probably tomorrow

ZackOP•4/27/25, 8:18 AM

If it's going back to the primary to pull the entire database I can see that being part of the reason for this. Pulling 2.5GB from WEUR to APAC or OC will surely take more than a few hundred ms. I feel like caching the checkpoints in each region would help significantly there, especially if you immediately boot the database and then sync the changes after. Clients that specify they don't care about any checkpoint could theoretically get the same performance as the primary, if it's cached

ZackOP•4/27/25, 8:18 AM

I'm sure there's significant complications to doing something like that though that I can't see from the outside

ZZack If it's going back to the primary to pull the entire database I can see that bei...

lambrospetrou•4/27/25, 8:22 AM

Pulling 2.5GB from WEUR to APAC or OC will surely take more than a few hundred ms.

Yeah, but in theory only the TTFB will be the significant difference, again with many caveats here.

Hopefully we will get the non-blocking replica boot soon, so this won't be a problem even without caching the snapshots in all regions.

ZackOP•4/27/25, 8:23 AM

Yea that would be a significant improvement

Llambrospetrou > Pulling 2.5GB from WEUR to APAC or OC will surely take more than a few hundred...

ZackOP•4/28/25, 1:47 PM

Hey, so coming back with some more (correct) metrics now.
Firstly, these are significantly improved because we made a change to always query D1, regardless of if the response is cached in the CDN, this seems to keep D1 significantly warmer, and our response times are much better in general than before we added this.
Now, onto the data. As I said before, errors are basically gone now, however we still get latency spikes. I've drilled into this pulling some data split by region, this is specifically metrics around the D1 call from the worker.
As you can see (in this 95th percentile graph), OC is our worst offender here, it occasionally has significant spikes in latency, sometimes going over a minute.
It is currently nighttime there, so we don't have many requests going through for OC, however a minute is still significant.
As we said, the upcoming changes around bypassing the replica when it's booting up would help this for sure, but a minute still seems pretty excessive

ZackOP•4/28/25, 1:47 PM

Lmk if you want me to pull any other metrics for you

ZackOP•4/28/25, 1:48 PM

A logarithmic version of the graph so you can see things are generally working normally other from those few OC spikes, one WNAM and one APAC spike

ZZack Hey, so coming back with some more (correct) metrics now. Firstly, these are sig...

lambrospetrou•4/28/25, 2:45 PM

Thanks a lot for the numbers! Yeah, the minute latency is almost always due to very slow network/retries/failures.
We will prioritize the non-blocking replica cold starts which will eliminate all this noise.

ZackOP•4/28/25, 2:48 PM

Yea makes sense, hopefully you can solve those slow starts too at some point, it feels like caching all that data locally within the DC would help there surely, as you don't have to pull up to 10GB across multiple oceans

ZackOP•4/28/25, 2:48 PM

For now, keeping the database warm by calling on every request is working for us, we can deal with these occasional slow starts for now

ZackOP•4/28/25, 2:49 PM

So we'll be mainlining replicas for now

ZZack So we'll be mainlining replicas for now 🙂

lambrospetrou•4/28/25, 2:59 PM

Keep us posted if you encounter anything else unexpected.

YYS•4/28/25, 8:23 PM

Are there plans to enable querying D1 from a database client like SQL developer?

YYYS Are there plans to enable querying D1 from a database client like SQL developer?

Cyb3r-Jak3•4/28/25, 8:32 PM

?d1-remote-connections

SuperHelpflare•4/28/25, 8:32 PM

Accessing D1 from outside workers:

D1 is based on SQLite, which does not natively support remote connections and isn't MySQL/PostgreSQL wire compatible, nor does D1 itself offer that functionality. As such, your options are:

1 -> The Cloudflare API Query Endpoint (https://developers.cloudflare.com/api/operations/cloudflare-d1-query-database), with the upside of needing less setup, 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.

2 -> Create a worker to proxy requests to your D1 Database. Either tightly bound to your application/schema or loose and just accepting any query. This would allow your worker to execute potentially closer to your D1 Database and avoid the api rate limit.

YYYS Are there plans to enable querying D1 from a database client like SQL developer?

Brayden•4/28/25, 11:10 PM

You can access your D1 from the open source Outerbase project which is a database client.

Madi•4/29/25, 6:03 AM

Hello,
Is there any workaround for D1's lack of geospatial indexing?

MMadi Hello, Is there any workaround for D1's lack of geospatial indexing?

Max (@rozenmd)•4/29/25, 8:30 AM

Hyperdrive + Postgres

Llambrospetrou Keep us posted if you encounter anything else unexpected.

ZackOP•4/29/25, 10:37 AM

Nothing more currently outside of the delays, which surprisingly are occuring more in WNAM atm. I was wondering if there is there is a better or worse region to be the primary region for your replica instance? Right now ours is in WEUR, but would ENAM or WNAM be better for instance, or maybe EEUR?

ZZack Nothing more currently outside of the delays, which surprisingly are occuring mo...

lambrospetrou•4/29/25, 11:16 AM

That really depends on your traffic patterns. There isn't a golden rule. All regions in the US and Europe are usually reliable and pretty good.

ZackOP•4/29/25, 11:17 AM

We get traffic from all over, mostly US and EU, but I was mostly wondering about the replicas spinning up in OC and APAC, is there a better primary location for that

sh4•4/29/25, 5:37 PM

Hi folks, apologies if this is already explained somewhere.. I noticed that via API I can create new D1 databases, but I cannot find information on how to direct a query on a per-worker-request basis towards a specific D1 Database. Imagine I have a multi-tenant SaaS with a new customer come in. Using the API I can create a new D1 database with just their data; But then imagine that user for that org wants to manipulate data in their database. I already know which requests should map to which database ID, but I have no idea how to construct/use a client for that database ID because it's not an environment binding.

Ssh4 Hi folks, apologies if this is already explained somewhere.. I noticed that via ...

lambrospetrou•4/29/25, 6:05 PM

Right now you need to have a d1 worker binding for each database you want to use from your worker.

sh4•4/29/25, 6:06 PM

I see. And that requires modifying the toml/jsonc, correct?

sh4•4/29/25, 6:06 PM

So if I want to onboard a new customer and them be able to query their own separate DB then that would require some manual work.

Ssh4 I see. And that requires modifying the toml/jsonc, correct?

lambrospetrou•4/29/25, 6:06 PM

It requires modifying and redeploying your worker, yes. Either through wrangler toml/jsonc or directly through the REST API for Patching the Worker settings. There are several threads in this channel with details on that.

sh4•4/29/25, 6:07 PM

Does patching worker settings update already-running workers? Thanks for the details.

Ssh4 So if I want to onboard a new customer and them be able to query their own separ...

Silvan•4/29/25, 6:55 PM

some people also use durable objects for this use case

Matthew•4/30/25, 5:12 PM

My Cloudflare Pages site is having problems connecting to D1. I've got 1000+ reports in Sentry of D1_ERROR: D1 DB storage operation exceeded timeout which caused object to be reset.D1_ERROR: D1 DB storage operation exceeded timeout which caused object to be reset. Looking at the D1 dashboard, query latency seems normal (p95 = ~1ms). But API routes that hit D1 are taking several seconds at best, or failing with the error above. The DB is in WEUR. This has been going on for about 6 hours now. Is there anything I can do to resolve?

Original message was deleted

Tait•4/30/25, 7:36 PM

I wonder about this too. However, I assume (possibly incorrectly) that there is a large silent majority who is not having issues.

gruntlord6•4/30/25, 8:37 PM

in general I haven't noticed any issues at all with d1, but I don't have hundreds of users or anything like that

Original message was deleted

lambrospetrou•5/1/25, 11:03 AM

I will reply assuming a friendly intent on your comment.

First of all there has been a lot of improvements over the past few quarters. We track the errors internally, and they are way less than say 8 months ago.
Second, there was big performance improvements for the Worker Binding requests, and soon similar improvements will apply to the REST API.
Third, read replication is finally out in beta, one of the most requested features. There were some rough edges initially, but they were fixed in a couple of days, hence why it was released as beta. This is going to be the basis for major simplifications like improving the exports of big databases for example. It will help scale reads significantly. And it's still early days in terms of smart placement of the replicas following your traffic transparently and all that.

Finally, if you scan ANY community forum, any channel in this Discord server, the vast majority of comments are negative. It's about issues people face exactly because this is a community support forum and they need help. That's the goal of these Discord channels. We have thousands of D1 users, some with thousands of databases literally, and you don't see them posting every morning that their services are running without issues.

People post about D1 having more errors than expected posting screenshots and experiences from last year or many months ago. It's not indicative to today. Yes, we have work to do around docs and improvements about these errors, but it gets better every day.

In closing, having said all the above, I by no means say D1 is perfect or that there is no justification to complaints. Yes, there are more errors than we want still, yes we are working on further improvements, and yes we are aware of most issues people raise. At the end of the day, if you use D1 and doesn't meet your needs, try Hyperdrive, DOs, or something else.

Matthew•5/1/25, 1:27 PM

After D1 was essentially unusable for ~6 hours for me yesterday, I created a new database in ENAM and migrated my data over it. Since then, I've had a handful of D1_ERROR: internal errorD1_ERROR: internal error on the new database. Hoping I don't have to do this migration more than once!

Brandon•5/1/25, 3:19 PM

hey all — brandon here (previously from Outerbase) we just shipped a new experience for D1 including our data studio. it's read only for now, but an editable experience is coming soon!

would love to get your thoughts!

BBrandon hey all — brandon here (previously from Outerbase) we just shipped a new experie...

James•5/1/25, 3:55 PM

love the new design and UX! One minor a11y comment about these: https://i.james.pub/file/2025/05/387f3575-9417-4610-a50c-c54484166e0f.png
github/deploy are buttonsbuttons that open new tabs so ideally should just be anchors so folks can middle click them and accessibility tooling understand what they do a little better :MeowHeartCloudflare:

BBrandon hey all — brandon here (previously from Outerbase) we just shipped a new experie...

Chaika•5/1/25, 5:58 PM

The sorting of queries/size is only for the DBs visible on the current page you are on, which is pretty confusing

Chaika•5/1/25, 5:58 PM

oh actually, not sure if that overview is strictly part of what you shipped? hmm

Brandon•5/1/25, 6:36 PM

Yeah we have a ticket open for this — right now the API is paginated, so sorting only applies to the current page. Hoping it's a fairly straightforward fix haha.

Successful-Arm-3762•5/2/25, 2:47 PM

Hi, been facing D1 network connection failure since some time now, on my production API.

Error: Database error during login: Error: D1_ERROR: Network connection lost.

Happens randomly.

Tim•5/2/25, 5:02 PM

My worker app is randomly getting errors like D1_ERROR: D1 DB storage operation exceeded timeout which caused object to be reset.D1_ERROR: D1 DB storage operation exceeded timeout which caused object to be reset..

The Cloudflare dashboard page for the worker shows 0 errors. However, I know this is happening, and have evidence in Sentry reporting.

James•5/2/25, 5:07 PM

It's generally recommended to build retries into your app for those kind of errors. Hopefully we'll see some official guidance soon for https://github.com/cloudflare/cloudflare-docs/issues/18485

Some more feedback: I reverted back to our original setup after a few hours, though we saw no errors

Similar Threads

Similar Threads

Similar Threads