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

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.