Global database comparison

Looking at Deno KV, DynamoDB, Fauna, PlanetScale and Upstash Redis on Deno Deploy

By Chris Knight, 20/06/2023 (last updated 19/09/23)

Deno recently launched a new global database, KV. Is it any good? In this post, we'll explore KV and other globally distributed databases to see how KV stacks up and what the best options are for use in Deno Deploy, examining latencies, characteristics and ease of use for performing common database interactions.

---

Contents

• Introduction
• Understanding database consistency
• Global database options for Deploy
• Latency experiment
• Latencies from your location
• Latencies from all over the world
• Analysis
• Final thoughts

---

Introduction

Before the cloud came along, a typical web application architecture would consist of a web server and a database. These typically were hosted in the same datacentre. This worked well for application teams (with everything in the same physical location), but not so well for users far away from the datacentre. The time it takes for data to travel a network, known as latency, for requests from the browser to the server could significantly impact the user experience.To help solve this problem of users far away, a new concept arrived, sometimes referred to as Edge hosting, where your application would be served from multiple global locations with the user being served from the closest location. This solved one problem of long latencies between the user's browser and the server. However, ironically, this made the experience worse for some applications and users as all those server to database calls were still going back to the original datacentre which could be far away from the user leading to increased overall response times.The next evolution in this journey are globally distributed databases, hosted in multiple regions around the world. By bringing the database closer to the user and server, both server and database are now closer to all your users around the globe and the latency for database calls can be significantly reduced. Other benefits include increased scalability as your traffic is split across many instances, as well as high availability with the ability to provide a database service even if one or more database nodes goes offline. Hooray! Problem solved right? Well, not so fast. It turns out that managing consistent state across each database instance spread around the world is a Seriously Hard Problem™.

There are a number of different approaches to solving this problem, each with trade-offs. One approach is to have a single primary region where all writes are sent to, and then asynchronously replicate those writes to the databases in other regions (often referred to as replicas). Writes can be potentially slower depending on how far away the primary region is from the user. Depending on the consistency model of the database (more on this below), reads can be looked at two ways:

• reading data which guarantees the most up to date data (referred to as strong consistency reads), but may be slower as these must be read from the primary region
• faster reads from the database region closest to the user or server, but may return stale data (referred to as eventual consistency reads) as the most recent updates in the primary database might not have made it to the user's closest database yet

As you can see the diagram above, if your application can tolerate eventual reads for some or most data, you can potentially save a significant amount of latency by not going all the way back to the primary region for reads. The downside is that you may read data which has been updated on the primary region but not yet replicated to the region you are reading from. This is the approach that Deno KV takes with the nice bonus that KV lets you choose if you want to read from a primary or replica database.

Understanding database consistency

In an ideal world, an update to one database would instantly update all the replica databases around the world making them all consistent with each other. Unfortunately, the same latency issues that we are trying to solve with global databases work against us here, as updating all the global replicas takes time. The speed of light is only so fast.

There are a number of different consistency models that databases can support. Two common ones are:

• Strong consistency: All reads are guaranteed to return the most recent write at the cost of higher latency
• Eventual consistency: Reads may return old/stale data, typically at much lower latencies, but will eventually return the most recent write. Under normal circumstances, you would expect database writes to be consistent within a number of seconds but many factors can influence this.

The PACELC theorem nicely describes the trade-offs between consistency and latency. Stronger consistency means higher latency and the reverse is true as well with weaker consistency allowing for lower latency.

Let's imagine you are located in Australia and the primary region of the database in the US but with a replica in Australia. If someone from France updates a record on the database (which gets sent to the US) immediately before you read that record in Australia, depending on your consistency model, you may get the old value (eventual consistency) from the Australia replica or the new value (strong consistency) from the US primary region.

The consistency model that you use for your application will depend on your application's requirements and what the database is capable of. If you are building a banking application where it is critical to ensure a financial transaction correctly debits one account and credits another for the same amount, you will likely want to use strong consistency and  ACID transactions. However, if you are building a social media application, eventual consistency of your user's posts may be a better choice as having slightly stale posts is potentially a worthwhile trade-off for the significant performance boost of eventual reads.

For a much more in-depth discussion on database consistency in a globally distributed database, this 4 part series is an excellent read.

Global database options for Deploy

Running applications on Deno Deploy means serving requests from locations around the globe, from a location closest to the user. Ideally, the database would be located close to the server so that latency between the server and database is minimised for all the database calls made from the server. Therefore an ideal database for Deno Deploy would be one which was globally distributed in multiple regions to decrease latency and thus provide a better user experience. In this post/web application, we'll experiment with the following serverless databases which all offer multi-region replication and work with Deno Deploy:

Deno KV

Deno KV is a new global key-value database from the Deno team (currently in open beta). Reads are strongly consistent within the primary region and eventually consistent in replica regions. You can easily choose which consistency level you want for your reads. It is built on top of the open source FoundationDB (used by Apple's iCloud) and there is no configuration or setup. Data is replicated to at least 2 datacentres in each replica region. Deno KV currently has 4 replica regions (US East, US West, Europe and Asia) available. Access is via a custom but simple API layer. ACID transactions are supported globally and offer strict serializability, the strongest level of consistency possible.

DynamoDB

DynamoDB is a serverless NoSQL key-value database from AWS. For access, it supports a custom JSON API as well as PartiQL (a SQL-compatible query language). DynamoDB tables, by default, are deployed to a single region. To achieve a multi-region setup, you can enable global tables which creates identical tables in additional regions (in as many regions as you like). Only a single region in N. Virginia was configured for this experiment.

Strong consistency is offered within a single region only but not for secondary indexes. Global tables are eventually consistent with each other. DynamoDB also supports ACID transactions, but only within a single region. Transactions are not ACID compliant when replicating to other regions. DynamoDB also integrates extremely well with other AWS services as well as offering a host of enterprise features such as encryption at rest and a multitude of back and restore options.

Fauna

Fauna is a serverless NoSQL document-relational database offering two query languages, Fauna QL (FQL) and GraphQL. During database creation, you must choose between two region groups to host your database: US or Europe. Data is replicated to 3 geographic regions within the region group (i.e. US or Europe), but never outside that region group. For this experiment the US region group was chosen. True global replication is possible (e.g. hosting in US, Europe and Aisa) but only for enterprise customers through their Virtual Private Fauna offering.

Fauna offers strong consistency for all reads and writes as well as supporting ACID transactions. Both Deno KV and Fauna provide the strongest consistency model of the databases in the experiment. Despite being a NoSQL database, a strength of Fauna is its relational database capabilities such as normalisation, joins and indexes.

PlanetScale

PlanetScale offers a serverless MySQL-compatible database built on top of Vitess and is the only true relational database of the experiment. It offers 11 AWS regions with 4 GCP regions. For this experiment, a primary region of N. Virginia was selected. Additional replica regions are only available on paid plans (starting at $29/month) and are therefore not included in this experiment. Being a relational database, access to the data is done via normal SQL queries. A key offering is the ability to change the schema in isolated branches, similar to a git workflow. All data is automatically encrypted at rest. Like MySQL, it only offers eventual consistency.

Though serverless, PlanetScale isn't necessarily hands off as when your database becomes large you may need to intervene and apply sharding, which can be complicated.

Upstash Redis

Upstash takes the well known in-memory Redis database a step further with a durable Redis compatible global database. Access is via Redis APIs. It offers per request pricing and which scales to zero price if not used (storage still accrues cost). Upstash Redis only offers eventual consistency. For this experiment, a primary region of N. Virginia was configured with replicas setup in all available replica regions (California, Oregon, Frankfurt, Ireland, Singapore, Sydney and Sao Paulo). N.b. this would be a potentially expensive setup for a high volume application.

Summary

Latency experiment

To be highly performant and give users the best experience, a globally distributed server needs a globally distributed database. How well does Deno's new KV database perform from regions around the globe and how does it compare to other globally distributed databases accessed from Deno Deploy?

Loading this page sent basic database write and read requests to each database. The database operations were executed from a Deno Deploy application running in the Google Cloud Platform (GCP) region/datacentre closest to you. Where the read or write operation was sent (i.e. which database region), and therefore the latency experienced, depends on how the database provider manages their network, where the primary database is, how many replicas are available, and what operation was used, amongst some factors influencing the latency.

All results represent the time for the database operation to execute, including the latency between the server (i.e. Deno Deploy application instance) and the database. The network latency between your browser and the server is not included in any result below.

The experiment aims to test the databases management and latency of global access. The queries are very simple and the data volumes are very small, both of which are unrealistic in a real-world application. By having simple queries and low volume data, the experiment allows the databases to perform at their fastest which in turn allows the experiment to focus on how the database provider manages the latency of global access.

The excellent WebPageTest was used to send requests to the different regions and provide the initial population of results.

Database latencies from your location

Upon loading this page, the following results were recorded for database requests from the Deno Deploy application (running in the region closest to you) to the various databases:

Your Deno Deploy region: N. Virginia

Database latencies from all over the world

Performance results from everyone who has loaded this page are summarised below, with stats updated daily.(Performance entries are held in Deno KV which returned and processed statistics for 0 performance measurements across 34 regions in 151ms.)

Analysis

Deno KV

DynamoDB

Fauna

PlanetScale

Upstash Redis

Final thoughts

The goal of this experiment was to put KV through its paces and compare it to other globally distributed database options for use on Deploy. Having done this, it is clear that KV is a serious contender and a very impressive database. The team appear to have made a great choice by using FoundationDB as the base to work on top of. With one of the strongest consistency models, some of the fastest performance and best in class ease of use, it's an obvious choice for many use cases.

In terms of individual databases, Fauna is talked highly of in technical circles and I can see its potential. However, I can't get away from its complexity. Developer time is expensive and unless Fauna really fit the project need, the cost of bringing the team up to speed with the database would be high. It's 'global' offering is also disappointing, though may improve in the future. Being limited to GraphQL API only (i.e. and not FaunaQL) on Deploy is also a potential drawback.

DynamoDB was one of the first serverless databases. Clearly it has proven itself and is a solid choice used by many companies large and small. To me, it feels like a database that has been around for a long time and is showing its age. It's highly performant, but has a mixed consistency model and the global tables feels like a bolt on rather than a core feature. Also, it was the only database in this experiment to incur a cold start penalty. That said, it's hard to beat it's enterprise features and AWS integrations. I found the lack of documentation on Deno usage very frustrating, though now that npm specifiers are supported in Deploy this should hopefully allow users to follow node based documentation.

PlanetScale was a surprise to me having heard great things about it. Technically it is impressive with Vitess and thus a sharded distributed relational database. Read performance is disappointingly slow. The need to manually shard your database once it degrades or runs into infrastructure problems is a turn off for me and runs counter to the serverless concept. Admittedly, few projects will ever need to undertake this. The schema management features are impressive and it's the definitive database in this experiment which can best handle relational data (N.B. Fauna also handles relational data and it would be interesting to pit these two against each other with complex scenarios around relational data). Finally, while storage is expensive, you get an astonishing amount of reads and writes for your money. If you use your database heavily with many reads/writes PlanetScale could make a very compelling case on price.

I loved how easy it was to get up and running with Upstash and those familiar with Redis will feel right at home. The simplicity of their serverless pricing model is really nice as well as the ability to customise replica regions. The pricing of reads and writes is expensive and so enabling lots of replicas could be costly. Write performance was also disappointing.

This leaves us with Deno KV. Going into this experiment, I didn't expect it to hold up as well as it has against the big hitters. Comparing to DynamoDB, it's as fast doing writes and faster doing reads thanks to replica regions (yes, it's not a fair comparison without enabling global tables in DynamoDB). Impressively, it achieves this with a stronger consistency model. The API is much easier to use than DynamoDB. It's also just such a joy to start coding with since there's nothing to install, setup, configure, etc. Whether you are coding for Deploy or locally, the KV database is just there waiting to be used. This will boost team creativity and productivity (less barriers) as well as reducing development costs. As a beta product, it's still lacking in a number of features. If you are already hosting on Deploy, using KV could be free if you stick within plan limits but pricing will quickly become much more expensive compared to other databases if you consistently read or write more than the plan limits.

Ultimately which database you choose will depend on your use case. If you need relational capabilities, go with PlanetScale or Fauna. If you need enterprise features or AWS integrations, DynamoDB is an solid choice. If read performance is critical, and you can tolerate eventual consistency, Upstash Redis may be your best choice. However, for many projects on Deploy, I would highly recommend KV.

---

Thank you for reading. I hope you found this experiment useful. If you have any questions, comments, or real world experience you want to share please reach out in the project discussions. Code for the experiment may also be found in the github repo.

Disclaimer:I have no affiliation with any of the companies mentioned in this article and am a first time user of each of the databases in the experiment.