Serverless vs Provisioned Throughput

Module: Design and Implement Data Models

Section: Sizing and Scaling

Lesson: Serverless vs. Provisioned Throughput

Introduction: The Architecture of Capacity

When designing modern data architectures, one of the most critical decisions an engineer faces is how to allocate capacity for their database systems. In the past, this was a relatively simple task: you estimated your peak traffic, bought enough hardware to handle that load, and hoped your projections were accurate. Today, the landscape has shifted toward cloud-native databases that offer two distinct operational models: Serverless (on-demand) and Provisioned (reserved) throughput. Understanding the trade-offs between these two is not just an infrastructure exercise; it is a fundamental aspect of data modeling that impacts performance, cost, and developer productivity.

Choosing the wrong model can lead to significant issues. If you choose a provisioned model for a highly unpredictable workload, you may find yourself overpaying for idle capacity or, worse, experiencing service outages because you underestimated a spike in demand. Conversely, choosing a serverless model for a high-volume, steady-state application might result in higher monthly bills compared to the discounted rates often available through reserved provisioned capacity. This lesson explores the technical mechanics, economic implications, and strategic considerations of both models to help you make informed architectural decisions.

Understanding Provisioned Throughput

Provisioned throughput is the traditional model of capacity management. In this setup, you explicitly define the amount of read and write capacity your database needs to handle at any given moment. You are effectively "reserving" a lane on a highway. Whether you use that lane or not, it remains yours, and you pay for the privilege of having it available for your exclusive use.

The Mechanics of Provisioning

When you provision capacity, you are configuring the database engine to allocate specific hardware or software resources to your workload. In many cloud databases, this is expressed in units such as Read Capacity Units (RCUs) and Write Capacity Units (WCUs). If you provision 1,000 WCUs, the system guarantees that you can perform 1,000 standard write operations per second.

This model relies heavily on your ability to perform capacity planning. You must analyze your application's history, understand your traffic patterns (seasonal spikes, time-of-day variations), and set thresholds accordingly. Many systems allow for "Auto-scaling" on top of provisioned capacity, which provides a middle ground by automatically adjusting the provisioned amount based on real-time metrics.

Callout: The "Idle" Trap A primary characteristic of provisioned throughput is that you pay for the allocated capacity regardless of actual utilization. If you provision for a peak of 5,000 requests per second but your average traffic is only 500 requests per second, you are paying for 4,500 units of capacity that are essentially sitting idle. This is often the primary driver for teams to transition toward serverless models.

When to Choose Provisioned Throughput

Provisioned throughput is generally the superior choice for workloads with predictable, steady-state traffic. If your application has a consistent baseline of activity—such as a internal dashboard, a steady-state logging service, or a legacy application with well-understood usage patterns—provisioned throughput provides the most cost-effective path. Furthermore, for applications where latency is strictly measured in single-digit milliseconds and any "cold start" overhead is unacceptable, the dedicated nature of provisioned resources provides a more stable performance profile.

Understanding Serverless Throughput

Serverless throughput—often referred to as "on-demand" capacity—removes the need for manual capacity planning. Instead of reserving a specific amount of throughput, the database provider automatically scales capacity up or down in response to your application's actual traffic. You pay only for the requests you make, rather than the capacity you have reserved.

The Mechanics of Serverless

In a serverless model, the database infrastructure is abstracted away from the user. When a request arrives at the database, the system instantly processes it and bills you based on the volume of data processed or the number of operations performed. There is no "provisioning" step; you simply point your application to the database endpoint and start sending data.

This model is inherently elastic. If your application experiences a sudden surge—perhaps due to a marketing campaign or a viral event—the database system handles the scaling behind the scenes. You do not need to intervene or adjust configuration settings. This allows developers to focus entirely on application logic rather than infrastructure management, which can significantly accelerate the development lifecycle.

The Trade-offs of Serverless

While the convenience of serverless is undeniable, it is not without its challenges. The most significant trade-off is cost at scale. Because serverless providers take on the risk of managing the underlying infrastructure and scaling, they charge a premium per request. If your application has high, consistent traffic, the cumulative cost of serverless requests can quickly exceed the cost of a reserved, provisioned instance.

Note: The Cold Start Phenomenon In some serverless database implementations, if a database has been idle for an extended period, the initial request might experience a slight delay while the system "wakes up" or initializes the necessary compute resources. While modern providers have minimized this, it remains a factor to consider for latency-sensitive applications.

Comparison Table: Serverless vs. Provisioned

Practical Implementation: Configuring Throughput

To illustrate the difference, let’s look at a common scenario in a cloud-based NoSQL database like Amazon DynamoDB.

Configuring Provisioned Throughput

When using the AWS CLI or SDKs, you define the throughput at the table creation level. You are responsible for monitoring the ConsumedReadCapacityUnits and ConsumedWriteCapacityUnits metrics in CloudWatch.

# Example: Creating a table with Provisioned Throughput
aws dynamodb create-table \
    --table-name UserProfiles \
    --attribute-definitions AttributeName=UserID,AttributeType=S \
    --key-schema AttributeName=UserID,KeyType=HASH \
    --provisioned-throughput ReadCapacityUnits=50,WriteCapacityUnits=50

In this example, we have explicitly told the database to reserve capacity for 50 reads and 50 writes per second. If we exceed these limits, the database will throttle our requests, returning an error to the application. To prevent this, we might implement auto-scaling policies that adjust these values based on actual usage.

Configuring Serverless Throughput

In the serverless model, the configuration is simplified. You simply select the "On-Demand" mode during table creation.

# Example: Creating a table with On-Demand (Serverless) Throughput
aws dynamodb create-table \
    --table-name UserProfiles \
    --attribute-definitions AttributeName=UserID,AttributeType=S \
    --key-schema AttributeName=UserID,KeyType=HASH \
    --billing-mode PAY_PER_REQUEST

By selecting PAY_PER_REQUEST, we tell the provider that we do not want to manage throughput. The system will handle any amount of traffic we throw at it, and we will be billed based on the total number of operations performed rather than a reserved capacity.

Best Practices for Scaling Decisions

Deciding between these two models is rarely a "set it and forget it" task. As your application evolves, your throughput needs will change. Here are the industry-standard best practices for managing this transition.

1. Start with Serverless During Development

For new applications, always start with serverless throughput. You do not yet know your traffic patterns, and the cost of over-provisioning during the development and testing phases can be avoided by using the pay-per-request model. Once the application reaches production and you have several weeks or months of usage data, you can analyze the costs and determine if switching to provisioned throughput would result in significant savings.

2. Implement Threshold Alerts

If you choose the provisioned model, you must set up alerts. Configure your monitoring system to notify your team when your consumed capacity reaches 70-80% of your provisioned capacity. This gives you a buffer to increase your provisioned limits before your application starts experiencing throttling errors.

3. Use Reserved Capacity for Baseline

Many cloud providers offer "Reserved Instance" pricing for provisioned throughput. If your analysis shows that you have a consistent, non-negotiable baseline of traffic (e.g., 200 writes per second), you can purchase reserved capacity for that baseline to receive a significant discount. You then use standard provisioned throughput or serverless for any traffic spikes above that baseline.

4. Monitor for "Throttling" Events

Regardless of the model, you should monitor your database for throttling events. Throttling is the primary indicator that your scaling strategy is failing. In provisioned models, it means you need to increase capacity. In serverless models, it might indicate that you have hit a "per-table" or "per-account" limit that requires a conversation with your cloud provider or a re-architecture of your data partition key.

Tip: The Partition Key Strategy Scaling is not just about throughput units; it is about data distribution. If your partition key is poorly designed—for example, if you use a "Status" field like "Active" or "Inactive" as your partition key—you will create a "hot partition." Even with serverless throughput, a hot partition will cause performance degradation because the database cannot spread the load across its internal infrastructure. Always ensure your partition keys have high cardinality.

Common Pitfalls and How to Avoid Them

Even experienced architects fall into traps when managing database throughput. Here are the most common mistakes and strategies to avoid them.

Pitfall 1: The "Auto-Scaling" False Sense of Security

Many engineers believe that enabling auto-scaling on a provisioned table eliminates the need for capacity planning. This is incorrect. Auto-scaling is reactive, not proactive. It takes time for the system to detect a spike, trigger a scaling event, and for those new resources to become available. If a flash-sale or a sudden traffic spike occurs, your application may experience minutes of throttling before the auto-scaling kicks in.

• Solution: For highly volatile workloads, consider the serverless (on-demand) model instead of auto-scaled provisioned throughput. If you must use provisioned, over-provision slightly during known high-traffic events.

Pitfall 2: Neglecting the Cost of "Read-Heavy" vs. "Write-Heavy"

Different operations cost different amounts. In many systems, a write operation is significantly more expensive than a read operation. If your application suddenly shifts from a read-heavy workload to a write-heavy workload, your costs will skyrocket regardless of whether you are using serverless or provisioned throughput.

• Solution: Regularly audit your application's read/write ratio. Use tools like CloudWatch or database-specific performance insights to identify which types of operations are consuming the most capacity.

Pitfall 3: Ignoring Regional or Account Limits

Cloud providers impose hard limits on how much throughput you can scale to in a single account or region. If you rely entirely on serverless scaling, you might find yourself hitting these account-level limits during a massive, unforeseen surge in traffic.

• Solution: Keep a "Service Quotas" dashboard in your cloud console. If you expect a massive growth event, request a limit increase from your provider well in advance.

Deep Dive: The Economic Perspective

When we talk about "scaling," we are ultimately talking about the economics of the business. Let’s look at how to calculate the crossover point between serverless and provisioned models.

Suppose you have an application that performs 100,000 read operations per day.

• Serverless Pricing: $0.25 per million reads.
• Provisioned Pricing: $0.0007 per RCU-hour.

If you use Serverless, your daily cost is: (100,000 / 1,000,000) * $0.25 = $0.025 per day.

If you use Provisioned, you need to calculate how many RCUs you need. If you spread those 100,000 reads evenly over 24 hours, you need approximately 1.2 RCUs (100,000 / 86,400 seconds). However, you must provision for your peak, not your average. If your peak is 10 reads per second, you need 10 RCUs. 10 RCUs * 24 hours * $0.0007 = $0.168 per day.

In this scenario, the Serverless model is significantly cheaper. However, if your traffic grows to 100 million reads per day, the math shifts. Serverless would cost $25 per day, while Provisioned (assuming a peak of 2,000 reads per second) would cost roughly $33.60 per day. As you scale, the gap closes, and the predictability of provisioned costs becomes more attractive for financial forecasting.

Advanced Scaling: The Hybrid Approach

In complex enterprise environments, you rarely choose just one model. Most mature architectures use a hybrid approach.

For example, a global e-commerce platform might use:

1. Provisioned Throughput with Reserved Capacity for the core product catalog, which has a constant, predictable stream of traffic.
2. Serverless Throughput for user-generated content, such as reviews or profile updates, which fluctuate wildly based on marketing events.
3. Provisioned Throughput with Auto-scaling for order processing, which has predictable daily cycles but occasional, extreme spikes during holiday sales.

By segmenting your data models based on the traffic patterns of the underlying data, you can optimize both performance and cost. Do not feel obligated to apply a "one size fits all" strategy to your entire database infrastructure.

Troubleshooting Throughput Issues

When performance degrades, the first step is to distinguish between throughput issues and latency issues.

1. Throttling: If you see ProvisionedThroughputExceededException or similar errors, your database is physically unable to handle the volume. You must scale up or optimize your query efficiency.
2. Latency: If you see high latency but no throttling, your problem is likely not capacity. It could be an inefficient query, a lack of indexes, or a network bottleneck. Throwing more throughput at a latency problem will not help; it will only increase your bill.

Callout: The "Query Efficiency" Rule Before adding throughput, always optimize your queries. A query that scans a million rows to return one result will consume a massive amount of throughput. If you add an index that allows the database to find that result in a single lookup, you effectively reduce your throughput requirements by orders of magnitude. Efficiency is the most cost-effective way to "scale."

Summary and Key Takeaways

Scaling and sizing are not just about adding more power; they are about aligning your infrastructure with your business needs. By understanding the nuances between serverless and provisioned throughput, you can build systems that are resilient, cost-effective, and easy to manage.

Key Takeaways for Your Architecture:

• Understand Your Baseline: Provisioned throughput is ideal for predictable, steady-state workloads. Use it when you can accurately forecast your traffic and want to optimize for the lowest possible cost.
• Embrace Flexibility: Serverless throughput is the gold standard for unpredictable or variable traffic. It removes the operational burden of capacity planning and allows your infrastructure to scale instantly.
• Start Lean, Scale Smart: Always begin development with serverless models. Transition to provisioned capacity only when you have clear data on your traffic patterns and can justify the savings.
• Prioritize Query Efficiency: No amount of throughput will fix an inefficient data model. Before scaling up, ensure your partition keys are well-distributed and your queries are optimized with appropriate indexes.
• Monitor for Throttling: Throttling is a signal that your scaling strategy is failing. Use monitoring tools to identify capacity bottlenecks before they impact your end users.
• Hybridize Your Approach: Do not force a single strategy on all tables. Different data entities have different traffic profiles; match the throughput model to the specific needs of each entity.
• Watch the Economics: Regularly review your billing against your traffic. The crossover point where provisioned becomes cheaper than serverless is a dynamic target that changes as your application scales.

By applying these principles, you will move beyond simple infrastructure management and begin designing sophisticated data models that grow alongside your business. Scaling should be a deliberate, informed process—not a reaction to failure. As you continue to build and refine your data models, keep these trade-offs at the forefront of your architectural reviews.