Is Edge Compute Really Faster?
Benchmarking Edge Platforms
(With Databases)

TLDR

I built a platform for running your applications and data on the edge with TypeScript (Bun and Deno) and SQL with strong consistency (MySQL compatible that works with Prisma!).

Sign up for Early Access

What is the edge?

In the world of building web applications, there are many different types of architectures to choose from. You have choices such as servers, containers, JAMStack, fully static websites, serverless, and lately, the edge.

Before we dive in, let's discuss what "the edge" actually is. Put simply, it's having your code distributed on many servers around the world, then routing a user's request to the closest deployment. This means that your users experience low latency access to your apps no matter where they are located in the world.

I've read many articles that talk about the edge being the future of cloud computing. Platforms such as Cloudflare, Vercel, and Deno have made great strides towards this becoming a reality. Cloudflare has Workers, Vercel edge middleware and edge functions, and Deno allowing you to run Deno and WebAssembly at the edge. Promises of low latency, high scalability, and zero cold starts, are things that many of us could benefit from for our web applications and these companies offer great solutions on the way to getting us there.

At first glance it can seem like the edge is going to make your applications run faster because code is being executed close to your users, however, a very important aspect is often omitted when discussing the edge, and that is the data.

Why does data need to be at the edge?

Most applications these days will have some aspect of data storage to deal with. In the case of edge apps, even if your code is globally distributed and executed at the edge, having your database in a single region can actually make overall response times slower compared to having everything (code and data) in a single region, because round trips between your app and your database can add significant latency.

Nubo

This why I've been working on my own edge platform - Nubo. It allows you to run TypeScript apps on the edge and also access your globally distributed data at the edge.

Performance

There are many options for globally distributing your code and data, however, careful consideration needs to be taken when deciding on which platforms/services to choose for your applications.

I created a test application and deployed it using various combinations of platforms and services to see how they compare to Nubo.

• Deno Deploy with CockroachDB
• Cloudflare Workers with Cloudflare D1
• Vercel Edge Functions with CockroachDB
• Nubo Deploy with Nubo SQL

Is all this speed really necessary?

Short answer, yes. There have been many studies that show a correlation between slow response times on websites, and users leaving a website and even loss of potential revenue.

When I worked at Amazon, we had to make sure that any advertisements we designed would not exceed a certain size. This was to ensure that the site performed well, so as not to impact user experience, and ultimately loss in sales.

What else can Nubo do?

Along with the speeds that Nubo is able to achieve, there are many other features and design choices that will improve the user experience for your users, and your developer experience (which is just as important). Let's explore some of these features and design choices of Nubo.

Nubo Deploy

• Deploy TypeScript apps (Bun and Deno)
• Globally distributed
• Zero cold starts
• Works with Next.js, Vite, Express, Hono, and more

Nubo SQL

• Globally distributed data
• Strong data consistency
• MySQL compatible
• Works with Prisma
• Built-in compliance (GDPR, CCPA, LGPD, etc.)

Why TypeScript?

Because no one should code in plain JavaScript anymore. Seriously. Stop it.

Why Bun and Deno?

Bun is just amazing. It's almost become a drop-in replacement for Node, but with so many benefits that make it ready for the edge, such as fast startup times, built-in TypeScript support, and extremely fast installs (goodbye long builds).

Deno is also coming up fast in the TypeScript community. It will have a longer journey for adoption (although this has been shortened with NPM support), but it's a really great way to build smaller scripts and even applications with TypeScript.

Why strong data consistency?

The challenge with globally distributed data, is that you need to find a way to make sure that when it's requested from various locations around the world, each user has the most up to date version of that data. Eventual consistency means that you could end up in a situation where you have a write to your database in one region, and a read with stale data from another region. For many use cases this is not a problem. However, for applications such as e-commerce sites, you need to make sure that the stock count is accurately reflected everywhere. This is where strong consistency is required. It means that if there is an updated record in your database, you can be sure that anyone reading that value from around the world gets the latest version of that record.

The tradeoff here is that writes can take just a bit longer to complete. This is why Nubo SQL gives you the option to have strong consistency with slightly longer writes, or eventual consistency with fast writes and slightly longer global replication. You can choose the strategy that suits your requirements.

Why MySQL compatibility?

When a new database comes out with features such as high scalability, global data access, etc., I first assess what the effort will be for me to use this tech in my applications. It's always great to have the option to move your applications between platforms. For example, let's say you built your startup's application using Cloudflare Workers KV (Cloudflare's global data store). Now your startup has grown, and you have more complex querying requirements that go beyond what KV is able to offer. The migration from KV to something like MySQL can be a nightmare (depending on how tightly integrated your application is with KV). Therefore, it's always best to choose tech that allows you to move to another platform with minimal or, ideally, no changes to your codebase.

This is why Nubo SQL is wire compatible with MySQL. No need to learn some new proprietary query language. It's just MySQL. Many developers already know MySQL, or if you're using PostgreSQL, it's very easy to port to MySQL. Another benefit of this is that it allows you to use Prisma!

Why Prisma support?

The tools I use as a developer are very important to me. They not only help me to develop faster, but provide a host of other benefits that I don't want to compromise on. Prisma is the best way to have type safe access to your database, perform migrations, seed data, and more. You can even generate a prisma schema from an existing database. This is why support for Prisma is a must.

Something to note is that Prisma itself is not designed to work well at the edge, which is why Prisma created their Data Proxy. This allows you to deploy a light version of Prisma with your edge application, then send queries to the Data Proxy, which in turn proxies the requests to your database. However, Prisma's Data Proxy is only available in two regions - Frankfurt, Germany and N. Virginia, USA. This is not ideal if your code is running all over the world, bringing us back to the same problem as when your database was in a single region.

This is why Nubo has its own data proxy deployed to all the regions that Nubo SQL is available.

Do we really need compliance (GDPR)?

Unless you want to get fined because you stored an EU citizen's data in a non-GDPR compliant region, then yes, you do need to think about compliance. GDPR isn't the only data privacy regulation that exists. California has the California Consumer Privacy Act (CCPA), Brazil has LGPD, and many more countries/territories are beginning to adopt their own data privacy policies/regulations/laws. These policies can also come with hefty fines for non-compliance. This is why we as developers need to make sure we have full control over what data goes where.

Nubo is built with compliance in mind, allowing you to choose where the data is stored, so that when the time comes for a data access requests or audits, you can take the necessary actions to remain compliant.

What about MongoDB Atlas?

MongoDB Atlas now has an option to globally distribute your data. This data replication is only eventually consistent, which means that there is no data consistency guarantee when reading from different regions.

I also don't recommend going with NoSQL as your main data source. The structure that is provided by relational databases with the type safety from tools such as Prisma, is the best way to manage the data for your applications. For me, the argument between NoSQL and relational databases is similar to the argument between JavaScript and TypeScript. One allows you to do whatever you want (NoSQL / JavaScript), the other provides structure and safety for you to build large applications (relational database / TypeScript).

What about Google Cloud Spanner?

I really like the idea of Cloud Spanner. It's a multi-region SQL database with strong consistency. Recently Google released a PostgreSQL adapter for Spanner. This, however, comes with a lot of limitations and does not allow you to easily port your existing application to use Spanner.

What about FaunaDB?

It's always a risk when considering new tech for your applications. With FaunaDB you'll have to learn how to do things that are only specific to FaunaDB, such as Fauna Query Language (FQL). If the requirements for your application change and you need to move to another provider, you'll have to rewrite all of your Fauna specific code. Another aspect is that FaunaDB comes with GraphQL. GraphQL should NOT be used between your server and your database. GraphQL is designed to work between your client and your services.

What's next?

I'm excited about the progress so far on the platform. These benchmarks are just the beginning of what I'm hoping to achieve with the platform. Nubo is currently in private beta, so make sure to sign up to get early access to the platform once the private beta is completed.

Sign up for Early Access