Demystifying DBaaS Pricing: Towards Clearer Cost Management

Serverless has been one of the biggest productivity boosts for software engineering. And that’s because it lets us focus on business logic while someone else takes care of the infrastructure.

But there’s a potential tradeoff. While serverless should mean we can sleep easier knowing that the ops side is taken care of, some serverless products can leave us lying awake at night worrying about the bill instead.

That’s especially true when it comes to database-as-a-service (DBaaS) products. Frankly, some serverless databases have serious price transparency problems. Why is that? One fundamental reason is that many DBaaS providers have lifted existing DBMS systems, which were designed for a single tenant, and made them available as managed services.

In this article, we’ll look at the three main causes of hidden costs when it comes to serverless databases, as well as how we’ve solved those problems with TiDB Serverless.

Three Reasons DBaaS Can Incur Unexpected Costs

Let’s take a moment to look at what we mean by an “unexpected” cost. There’s a difference between the headline price of a tool and what it actually ends up costing you. It’s why product selection discussions usually focus on total cost of ownership, rather than what’s on the vendor’s pricing page.

Unexpected DBaaS Cost

Pay for Idle Workload	Cloud Optimization Gap	Operation & Integration
Whether your database is under load or sitting idle, the DBaaS vendor still has to pay their cloud bill.	Bad cloud optimization will pass the egress fees and the DBaaS provider’s cloud bill onto you.	Operational overhead and existing infrastructure integration.

To better understand how these factors contribute to the hidden costs of serverless databases, we’ll explore them in a little more detail.

1. How DBaaS Pricing Leads to Inefficiencies

Serverless pricing should be straightforward. If you use capacity, you pay for it. If you don’t use it, you don’t pay for it.

Take AWS Lambda, for example. While your script runs, you pay for the memory it uses. When the script isn’t running, you pay nothing.

Ideally, a serverless database should work in the same way. You pay for read/write operations and CPU time to power queries, for example, but otherwise billing can go to zero.

In practice, though, usage-based pricing is impossible for many DBaaS offerings. Instead, they charge a fixed hourly or monthly baseline fee for CPU, RAM, storage, and even the number of VMs required to run your single tenant database. That means you pay whether you use the database or not.

Challenges With Traditional DBaaS Pricing Models and Idle Resource Costs

• Fixed Pricing and Over-Provisioning: Traditional models often require provisioning for peak demand, leading to inefficiencies and unnecessary expenses during low-demand periods.
• Inefficient Resource Allocation: Resources often remain underutilized, contributing to higher operational costs.

How Does that Lead to Hidden Costs?

Let’s consider an example: a fitness app designed to keep homeworkers active.

This pattern results in four hours of peak activity and eight hours of moderate use on working days, with very low to no activity for the rest of the week.

As the lead developer of the app, you opt for a managed MySQL service so that your team can focus on delivering features not managing databases. But the DBaaS you choose doesn’t offer usage-based pricing. Instead, you’re forced to specify a package based on those four hours of peak demand. This means that for the remaining 20 hours each day, and all 48 hours of the weekend, the MySQL cluster is significantly over-specified and underutilized.

In an ideal scenario, your database would scale close to zero in off-peak times. But no matter what your actual usage, the DBaaS vendor charges you the same hourly fee.

2. The Cloud Optimization Gap

So, why is DBaaS pricing often like this? The crux of the issue lies in the mismatch between legacy database architectures and cloud-native requirements.

Most DBaaS providers take an existing DBMS tool and automate much of the operational side but otherwise leave the architecture untouched. When you deploy a database with a provider such as PlanetScale or Aiven, they commission and run a dedicated database cluster on your behalf on a public cloud..

Egress fees aside, the DBaaS provider’s cloud bill is the same whether you use the database or not. Naturally, they pass that bill onto you. If your database has predictable load, that’s less of a problem. But it makes it uneconomical for those vendors to offer serverless-style usage-based pricing.

3. Operational Overhead and Integration Surprises

Truly serveless offerings let you focus on business logic while the provider takes care of everything else. But the monthly bill is just one part of what a managed database costs you. Two other factors can play just as much, if not more, of a role in the total cost:

• The operational burden
• How well it integrates with your existing tech stack.

Integrating DBaaS

Potential Issue	Solutions
Incompatibility with existing tooling	Work with a DBaaS that is compatible with a popular, mainstream DBMS
Unfamiliar data models	Unless you absolutely need a different data model, choose a relational DBaaS
Potential for increased latency between the DBaaS and your application servers/microservices	Select a DBaaS region close to your other cloud services

The Hidden Costs of Operating DBaaS Products

The first might seem surprising. Managed tools are meant to take care of the operational burden. But this is another difference between a truly serverless database and a managed database.

Even if the provider takes care of networking, operating system updates, and security, in some cases you remain responsible for day-to-day database management tasks such as performance tuning, query optimization, and index maintenance.

Integrating DBaaS Products into Your Existing Infrastructure

Perhaps the hardest hidden cost to quantity is the impact that a database might have on your team’s productivity. Gauging the real toll on productivity can be tricky and it can be tempting to think that it’s only a problem with non-relational databases, such as MongoDB.

However, the bigger picture of integrating a DBaaS into your application architecture also covers:

• Tooling compatibility: Can your existing ORMs, infrastructure management tools, testing frameworks, CI/CD pipelines, and optimization resources effectively integrate with the DBaaS?
• Team familiarity: Does the database ask you and your colleagues to learn unfamiliar data models or an unusual SQL dialect, for example? Or can you get straight to work thanks to compatibility with standard tooling such as MySQL?
• Latency due to cloud location: Databases are often the most latency critical part of your application architecture. What does the DBaaS vendor offer to reduce the latency between your database and your application servers?

Breaking Down Cost Barriers: TiDB Serverless’ Approach to Transparent Pricing

TiDB Serverless represents a radical departure from traditional DBaaS offerings. By reimagining the database architecture for a serverless world, TiDB Serverless delivers on-demand pricing, eliminates hidden costs, and integrates seamlessly with your tech stack.

How TiDB Serverless Delivers On-Demand Pricing

As we’ve seen, when you create a new database with many managed database services, they typically spin up a single-tenant cluster exclusively for your use. That makes you solely responsible for paying for the underlying cloud resources whether or not you’re using them.

In creating TiDB Serverless, we quickly recognized that we’d need to redesign the architecture of our TiDB Dedicated product to make it suitable for a serverless model, while not only build-in efficiency, but also enables a scalable, pay-as-you-go pricing model. Here’s how we did it:

• Opted for a multi-tenant model: TiDB shares expensive underlying resources amongst multiple databases. That way, rather than unused resources sitting idle they’re distributed to where they’re needed.
• Adopted a microservices architecture: We examined the architecture of TiDB and split the primary components into smaller, decoupled services. That gives us finely grained control over scaling those services that are in-demand.
• Moved to shared block storage: Rather than allocating disk space to each database and then leaving much of it empty, TiDB Serverless uses elastic block storage both to make scaling much faster and to improve durability. In fact, data durability in TiDB Serverless is much higher than the typical three replace setup found with local storage and hits at least the eleven nines level.

TiDB Serverless High-level Architecture Design

With this approach, TiDB Serverless’s architecture is truly cloud native, working with the grain of the underlying cloud platform. And that means it is highly efficient, allowing us to offer truly serverless pricing and a generous free tier.

But what about the operational side? TiDB Serverless slots easily into your existing toolset and experience thanks to its MySQL compatibility. And operationally we’ve designed TiDB Serverless to operate autonomously. No individual servers are exposed to you as a developer, only the fully elastic data services.

Experience TiDB Serverless firsthand for free and discover its usage-based, granular, cloud-native pricing.

Learn TiDB Serverless Pricing

 

And stick with us. Over the coming weeks we’re going to be looking at other ways you can make savings on your database costs. Next up in the series is our developers’ guide making full use of 25GiB free storage quota with TiDB, and ways making sense of serverless billing.