This is going to sound crazy, but everything else is a workaround for this fundamental problem. So - I’m just going to say it and believe in the idea. My biggest problem with going full-stack on Cloudflare Workers is that our database is still land-locked to an RDS instance in a single region.
There’s no getting round the fact that, although compute is at the edge - the actual database (which is inherently necessary to provide any response to any API call for our SaaS app) - is in RDS, and right now - the benefits of being at the edge are pointless if a request still has to go all the way around the world to connect to a database and run SQL.
These might be considerations to think about this problem:
- The storage layer might be best suited to Durable Objects, as long as disk access, etc. is high latency.
- There needs to be a notion of auto-replicated Durable Objects - something that eventually looks like Google Cloud Spanner for ACID compliance when it comes to traditional SQL databases like Postgres.
- The notion of daemonizing every instance of Postgres does not have to be per database - it can be a shared instance across all customers, but I don’t know how.
- To enable a SaaS company (like us) to upsell compliance services like “Guarantee your data lives in Germany” - I know that my compute can be bound by jurisdiction, but I’d need row-level data storage in a Postgres schema to ensure that a specific row of a specific table is jurisdictionally-bound to a given geography. So - country-binding applies at 2 levels. First - ensure a Worker (compute) only runs in a given geography, Second - ensure a specific row, in a specific table can be app-specified to only be stored at rest in a given geography.
Obviously - replicating my database throughout the world is incredibly hard and costly at many levels, otherwise I could just stick with RDS and do that.
One big condition (the developer must handle) is that row-specific country-storage requirements need to be baked in on the Worker or compute layer - but we’re happy to re-factor and do that.
Yes, this is difficult. But the market is absolutely massive - databases like Postgres can actually shift wholesale to run on the edge, if this works. A ton of cloud spend just goes into keeping demonized database instances alive in traditional VM’s.
Thoughts? I’d especially love to hear from Cloudflare, because what I’m proposing is clearly audacious - but something I believe they’re capable of doing. Happy to answer questions on the requirements/use cases, as the “how” is a bit beyond my capability.
A first stage might be to have GET or read operations be served from the edge, via replication between RDS and a Postgres listener/mirror on Cloudflare. However, the goal can/should always be - to create a Postgres instance on the edge itself, which auto-replicates based on demand e.g. a high-traffic Postgres instance might make 8 read-write copies of itself (no master) across various Cloudflare nodes. The “read only” scenario is not worth considering, as achieving the entirety of the goal would really be disruptive. I could solve every land-locked RDS (Postgres) problem I have today by moving it to the edge, to get high performance, much less latency at much lower cost - a bit like what Amazon Aurora Serverless v2 is trying to do. That would be fundamentally change how people see Cloudflare as a whole, and would also encourage me to actually move our entire app-stack to Workers.