Explore key considerations when choosing a serverless database. This article compares popular databases to help you make an informed decision.
Serverless architecture, a paradigm that has been around for several years, has been transforming the way we build and deploy applications. In this approach, developers can focus on writing code without worrying about the underlying infrastructure. Instead of managing servers or virtual machines, they can rely on cloud providers to handle the scaling, maintenance, and availability of their applications.
While Serverless architecture has been around for a long time, it is only in recent years that the concept of Serverless databases has gained significant attention. Traditionally, databases, with their stateful and performance-sensitive nature, posed challenges in adopting a Serverless approach. However, the essence of databases is to simplify data management, allowing developers to concentrate on their core business goals. In this context, exploring and understanding Serverless databases can be valuable in the sense of enabling developers.
So, what should you consider when choosing a Serverless database? Let’s delve into the topic by comparing and analyzing popular serverless databases such as TiDB, MongoDB, Amazon Aurora, CockroachDB, and DynamoDB.
Suitability
When choosing a database, regardless of whether you’re using a Serverless architecture or not, it’s important to consider its suitability. Should you go for a general-purpose database or a specialized one? While specialized databases can be more convenient and advantageous in specific scenarios, they may not be the only crucial factor for technical teams. Sometimes, you need to balance the complexities introduced by multiple technology stacks, difficulties in talent recruitment, and the costs of operations and development.
Compared to traditional relational databases, NoSQL databases like DynamoDB or MongoDB are often considered to have better scalability and performance due to fewer limitations. However, users may end up paying a high price to compensate for the capabilities they give up with NoSQL. For example, they may need to ensure data consistency on their own and develop custom code for query and computation logic. From this perspective, relational databases like TiDB, Amazon Aurora, or CockroachDB offer more versatility but slightly less flexibility. Moreover, TiDB offers Hybrid Transactional/Analytical Processing (HTAP) capabilities, enabling users to analyze operational data directly without separate ETL processes. This simplifies infrastructure complexity for small to medium-sized users who don’t currently require complex data warehouses.
In conclusion, choosing the right database involves a careful evaluation of the trade-offs between specialization and generalization, considering factors such as scalability, performance, complexity, and the specific needs of your project.
Pay-As-You-Go Pricing Model
One of the core features of Serverless is the pay-as-you-go pricing. Almost all Serverless databases attempt to address a common challenge: how to provision resources economically and efficiently under uncertain workloads. Prioritizing lower costs may mean consuming fewer resources. However, in the event of unexpected spikes in business demand, you may have to compromise user experience and system stability. On the other hand, more generous and secure resource provisioning leads to resource waste and higher costs. Striking a balance between these two styles requires complex and meticulous engineering management. This would divert your focus from the core business.
Furthermore, the Pay-as-you-go billing model has varying implementations in different Serverless products. Most Serverless products offer granular billing based on storage capacity and read/write operations per unit. This is largely possible due to the distributed architecture that allows finer resource scaling. Amazon Aurora Serverless is an exception in this case – it employs a coarser billing model based on Aurora Capacity Units (ACUs), which roughly corresponds to 2GB of memory along with the respective CPU and network bandwidth. Additionally, it cannot scale down to zero ACUs. This can result in significant waste for infrequently accessed data, especially when you need to construct numerous small-scale clusters of this kind.
Moreover, each provider has its own pricing structure. In this regard, TiDB offers more affordable prices compared to others.
Scalability
In reality, the concept of Serverless databases inherently implies scalability. From 0 Transactions Per Second (TPS) to millions of TPS, Serverless databases should be able to automatically scale based on the workload. While database providers can use a single large database to handle different workloads, this approach would result in significant waste and higher prices. Therefore, users need to adjust the architecture of Serverless databases based on the actual workload.
In this regard, distributed databases have a clear advantage. Apart from vertical scaling, they rely primarily on horizontal scaling, which provides better scalability since vertical scaling easily reaches its limits. Compared with relational distributed databases, a NoSQL database offers better scalability due to the absence of strict transaction constraints. However, the reality is always more complex. For example, MongoDB’s Serverless offering is designed for small-scale users of less than one terabyte. Its dedicated offering requires manual sharding to achieve further scalability. On the other hand, TiDB and CockroachDB support horizontal scaling with auto-sharding, which enables better scalability.
As distributed relational databases, both TiDB and CockroachDB benefit from a storage-computing decoupled design. This enables near real-time scaling of the computing layer. Unlike CockroachDB, TiDB can leverage shared storage at the regional level for rapid and stable storage scaling within a few minutes.
TiDB Serverless Architecture
Rolling Upgrading
Database upgrades are unavoidable. Traditionally, they often involve downtime or disruptions to business continuity. However, in the Serverless database realm, minimizing or eliminating downtime during upgrades is a critical consideration. This is where distributed architectures excel. Their inherent fault-tolerant design allows for non-disruptive rolling upgrades of individual components without causing downtime. Non-distributed architectures face challenges in achieving non-disruptive upgrades. If we look at the major players, Amazon Aurora Serverless does not support non-disruptive updates, emphasizing the advantages of distributed architectures in this regard.
Connection Model
In traditional application models, developers typically prefer long-lived connections to databases instead of frequent short-lived connections. However, maintaining long-lived connections in Serverless applications is often challenging due to architectural limitations. On the other hand, using the HTTP protocol for data access has made it more convenient. Consequently, many databases now offer HTTP-based access interfaces to facilitate data retrieval and manipulation.
Professional Support and Services
Professional support and services are essential to consider when selecting a database, Serverless or not. It is crucial to assess the support provided by the vendors. While I cannot objectively evaluate specific products’ support services, it is valuable to consider the vendors’ reputation and responsiveness to user needs. For example, many TiDB users have expressed satisfaction with the vendor’s support, citing timely assistance and a willingness to incorporate user feedback for rapid product improvements.
Wrapping Up
In conclusion, Serverless databases have emerged as a powerful solution for data management in modern applications. By offloading infrastructure management and enabling scalability, they allow developers to focus on their core business objectives. When choosing a Serverless database, it’s crucial to consider various factors such as the applicable range, pricing model, scalability, rolling upgrade capabilities, and the availability of HTTP Data APIs.
Here’s a comparison summary of different Serverless databases we have covered in this article:
It’s important to note that this summary table provides a general overview, and the suitability of each database depends on your specific requirements and use case.
By carefully evaluating the characteristics and comparing them to your project’s needs, you can make an informed decision and select the most suitable Serverless database to drive the success of your application.