Relational Database Connectors for Cloudflare Workers | Hacker News Reader

Relational Database Connectors for Cloudflare Workers

blog.cloudflare.com

49 pointselithrar13 comments

If one HTTP request is split into many serial database queries (E.g 1:10, request:db-queries), it doesn’t make sense to have the request hit the low latency edge worker, and then send 10x the queries to a faraway database server as you are incurring the cost of latency for each db query.

In this case you may as well run an HTTP server next to your database and incur the high http request latency once, and have < 1ms latency for each of the 10 queries.

Is this correct?

If this works like a regular worker, the first request can then cache the response for subsequent users. Might be helpful for read-often, write-rarely use cases where the first user (per expiry period) acts as a sacrificial lamb to speed up subsequent requests for following users. Regardless of whether the Worker hits the 10 DB queries itself or goes through a database-adjacent HTTP proxy first, subsequent requests don't have to hit either one, but can get served directly from the Cloudflare edges using a cached response.

You can get similar caching by making a bunch of distributed read-only database shards and/or caching your HTTP proxy output, but in this case Cloudflare manages all that for you. You do have to set up a tunnel and apparently some sort of daemon, though, so I guess you're just running Cloudflare's proxy to their edge.

It's not as clean as an edge-native key-value store (like their Durable Objects or Workers KV), but if your existing code requires a relational DB at scale, this might be one way to tackle it rather than dealing with DB sharding and clustering yourself -- which can get real ugly, real fast.

I'd personally prefer if Cloudflare spent their time developing something like a global relational database that was wire compatible with Postgres.

My reasoning is that all their offerings are geared toward the edge, and while it's nice to support relational databases as they currently are, it seems to counter why you'd build on Cloudflare's edge to begin with.

This seems more to be suggesting that I should not pursue an edge-based architecture and stick with containers instead.

If I'm going to be using workers, I'm already giving up a ton of capabilities possible on a native OS. In return, I'd hope for something wild, like a fire and forget global relational database.

If my original ask was too tall an order, I think a global GraphQL service would fit nicer with their current stack and offer most of the same benefits as direct database access (i.e. schema as a service accessed over http).

If they add TCP support you can use any existing distributed SQL as a service product.

This is true - however, I still want to see an offering from Cloudflare because I expect them to put their money where their mouth is.

If they are going to push edge computing, they need to have a first-party answer to the major application needs. Having a third-party ecosystem of offerings is extremely welcome, but I don't think Cloudflare should be banking on these. They need to develop an in-house solution - why should I be confident that edge solutions are better when they cannot offer me a competitive storage solution?

Durable Objects is awesome, but it's complementary. They need to offer a datastore.

Hey, I'm on the PM team at Cloudflare.

I think this is exactly right, but the truth is that developers are slow to adopt new databases and databases are slow to support a broad array of use-cases. While we're also working on that piece, we think we can make relational databases easier to use and faster by caching them at our edge. To cache them, you have to connect... hence this announcement :)

Thanks for replying, Greg! If my post seemed overly negative, please interpret it more as constructive feedback.

Databases are a tough challenge, but I'm happy to hear you are trying to tackle it head on - I've been following the developments in storage from Cloudflare quite closely because the potential is massive.

Or we could do both?

I eagerly await :)

I'm a little confused as to why someone would use this.

There are a lot of benefits to keeping an entire instance of a service in one DC. BW is plentiful, latency is low, and a whole host of tools are at your disposal. Of course, there are downsides too, mainly latency to users and sensitivity to DC outages.

On the other hand, running things at the edge basically has the opposite tradeoffs. Good latency to users and tolerance to DC outages, but hard to rely on everything "behind" the service to be running in the same cluster. And fewer tools support this deployment environment.

For their past compute/storage offerings, Cloudflare seemed to be pursuing the latter while trying to minimize the downsides. I think this is a good strategy since it offers value without directly competing with the major clouds.

But this seems to combine the downsides of both approaches (localize to a DC and run on the edge) while offering none of the advantages. It seems better (in this case) to use the edge as a proxy and just run the code in the DC.

I'm curious, what's the intent here? To transition people from AWS Lambda to CF Workers?

I think those architectures you mentioned come from entirely different philosophies.

The data center model relies on a glob of services that you manage yourself, and manage infrastructure & networking for. That's how a lot of the early AWS services were built. AWS still offers that paradigm, especially for bigger enterprises that want or need that level of control.

But Cloudflare fast-forwards all that by a few generations, which makes their edge computing MUCH easier, faster, and cheaper to use than Lambda or similar services. Instead of worrying about specific data centers, interconnect, firewalls, bandwidth, etc., on Cloudflare the topology is mostly invisible (unless you have to deal with the Chinese Firewall). You just upload your stateless Javascript code into a worker, and it gets replicated everywhere nearly instantly. Replication and caching are handled invisibly by Cloudflare and you never really have to think about it. If you need state or durable storage, their edge storage products (Workers KV, Durable Objects) function similarly... a few lines of code and you've got a globally scaled auto-replicating data store that you never have to manage the infrastructure for.

The benefit is that it's way easier than having to manage network infrastructure, and Cloudflare's offering is far superior to anything a small business could easily set up or maintain on their own. If you're a huge enterprise, maybe there's more concern about how much control you have over the topology, caching details, etc.

But for simpler websites and apps, the Cloudflare stack is tremendously easier to work with than anything AWS offers, waaaaaaay faster (especially for cold starts), and usually much cheaper.

Workers isn't a 1:1 replacement for Lambda, but it's probably the better choice for simpler functions.

As for this database connector, it goes against their edge-native offerings, but it's probably just there as a compatibility layer for people who aren't able to rearchitect their whole stack yet. Like their other CDN products, this lets you connect legacy stacks (single host or single data center) to a global CDN with little work.

hi there! i'm on the workers team at cloudflare.

you're right that the ideal application would run fully on the edge (which is why we try to offer things like KV, Durable Objects, and more options in the future for you to have your data where your logic is running).

however — moving your data to the edge is unlikely to happen overnight. and it's going to take us a bit to offer you all the data options for all the different use cases that you need (after all, there are many types of databases for a reason), so this gives users greater optionality. secondly, if your data is already somewhere but you want to build new features on top of it, now you can. (say, i already have a database with all my apartment listings in it, but i want to add a new feature where i let my users add photos of the apts). i can now build that feature in workers, without having to undergo an otherwise massive migration.

one last thing, this is just the beginning of what even database connectors mean. in the future, we can cache data, and actually improve performance and reliability even if the dc is far (as you said, make it easier to have best of both worlds).

Thanks for the response! I hadn't considered that last trick. If you can make it work well, it will be pretty cool.

Reply on news.ycombinator.com