| ▲ | piterrro 2 hours ago | |||||||||||||
I’m running entire leadjobs.dev on cloudflare workers and its kind of unreliable for the traffic it gets - around 100 visitors/day. There are some weird errors in d1 from time to time which i cannot debug since its all black box. Also latencies are greater than I would expect, especially, again for d1. Overall its great value for money to get a globally available, low latency service - but I would think twice before going all in. As a sidenote, I expected that, thus the architecture of the service is build in a way that it abstracts the cf runtime and I can switch to any other infra, be it dedicated or another cloud, in a matter of a day | ||||||||||||||
| ▲ | kentonv 2 hours ago | parent [-] | |||||||||||||
I'll let you in on a sort of dirty secret: It's almost always better to use Durable Objects storage, rather than D1. Even if you only want a single global database, it's better to implement that as a singleton Durable Object, than by using D1. Because that's all D1 itself actually is: a singleton Durable Object that exposes an API to its SQLite database. It's just a wrapper. With raw Durable Objects, you get to bring your code to run on the same machine as the database itself. Your queries run on a local file, synchronously, rather than going over a network. There is essentially zero latency when using sqlite storage in a Durable Object. If your app does no more than one DB query per request, then D1 is fine: the Worker runs near the end user, and talks over the long-haul network to D1 just once. Whereas with Durable Objects, your Worker would talk over the long-haul network to the Durable Object. No difference. But if your app ever does two or more queries in series for a single request, then Durable Objects becomes vastly better, because you get to move that query-chaining code to happen directly where the database lives, rather than have multiple round trips. Really, though, the only reason D1 exists is for comfort. Once you know how to use Durable Objects, there's no reason to use D1. We offer D1 because a lot of people don't want to learn a new model. (Which is fair. People are busy and may have better things to do.) One caveat: D1's read replica support still isn't exposed in a way that you can use it in raw Durable Objects, so if you are using that, it's a legitimate advantage to D1. But we do plan to bring this functionality to raw Durable Objects at some point. | ||||||||||||||
| ||||||||||||||