Drawbacks of Moving to the Edge
Edge runtimes are often lauded as a fix to all latency concerns. But sometimes, moving to the edge can increase latency.
The problem: databases are still regional. If you move your application logic closer to the user via edge functions in multiple regions, this most likely increases the distance between your application and your database. Since the latter is often more chatty (more data sent back and forth between the application and database than the user and the application), this usually increases latency.
Could you make data multi-regional? Sort of. There’s so work being done to bring the database to the edge (see distributed SQLite), but now with stateful data at the edge, you have a complicated distributed systems problem.
Smarter caching? There’s also some work being done in application frameworks to do smarter caching (e.g., stale-while-revalidate) so that users get fast responses for most of the application while new data is rehydrated.
Matt -- This observation was one of our primary motivations for Sands Capital Ventures (the venture arm of Sands Capital) investing in pgEdge. pgEdge is fully distributed PostgresSQL, optimized for the network edge and deployable across multiple cloud regions, data centers and even across multiple cloud providers. And the magic is that pgEdge is a true multi-active distributed database system that allows read and write operations to take place any node on the network. And this one is particularly fun for us, as several on our team backed Phillip Merrick (CEO) at webMethods and EnterpriseDB more than 20 years ago! Ping my if you'd like to learn more. Good stuff!!