Serverless Databases

# CHAPTER 7

Serverless Databases #

1. Introduction #

2. Learning Objectives #

• Identify the bottleneck of traditional databases in a serverless environment.

• Define a Serverless Database.

• Differentiate between NoSQL (DynamoDB, Firestore) and Relational Serverless (Aurora Serverless, Azure SQL Serverless).

• Understand DynamoDB Partition Keys and connectionless architectures.

• Conceptualize a serverless CRUD application.

3. Beginner-Friendly Explanation #

• Traditional Database: A massive, single water tank with 50 pipes (Connections). If 50 people turn on their faucets, it works fine. If 10,000 people suddenly turn on their faucets, the 50 pipes burst and the tank explodes.

• Serverless Database: An intelligent reservoir with no fixed pipes. If 1 person asks for water, it instantly creates 1 tiny pipe. If 10,000 people ask simultaneously, it instantly creates 10,000 pipes, delivers the water perfectly, and then dissolves the pipes. You only pay for the exact drops of water consumed.

4. The Connection Pool Problem #

*The Solution:* Use an HTTP-based NoSQL database (like DynamoDB) that requires no persistent connection, or use a Connection Proxy (like AWS RDS Proxy) for relational databases.

5. The Giants of Serverless NoSQL #

• Amazon DynamoDB: The king of serverless data. It provides single-digit millisecond performance at any scale. It communicates via HTTP APIs, completely eliminating the connection pool problem. You are billed purely on Read/Write Request Units.

• Google Cloud Firestore: A highly flexible, document-based NoSQL database that offers real-time synchronization (perfect for chat apps or live dashboards).

6. Relational Serverless Databases #

• Amazon Aurora Serverless: A relational database (MySQL/PostgreSQL compatible) that automatically scales its compute capacity up and down based on load, and can scale to zero when unused.

• Azure SQL Database Serverless: Automatically pauses the database during inactive periods and resumes instantly, billing you only for the compute seconds you use.

7. Mini Project: Conceptual Serverless CRUD #

Step-by-Step Overview:

1. 1. The Database: In AWS, you create a DynamoDB Table named Users. You set the Partition Key to userId.

1. 2. The Roles: You create an IAM Role granting your Lambda function permission to dynamodb:PutItem and dynamodb:GetItem on the Users table.

1. 3. The Compute: You write a Lambda function. Because DynamoDB uses HTTP APIs, your code doesn't open a persistent SQL connection. It simply uses the AWS SDK:

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { PutCommand, DynamoDBDocumentClient } from "@aws-sdk/lib-dynamodb";

const client = new DynamoDBClient({});
const docClient = DynamoDBDocumentClient.from(client);

export const handler = async (event) => {
    // 1. Extract user data from the API Gateway request
    const user = JSON.parse(event.body);
    
    // 2. Insert into DynamoDB instantly
    const command = new PutCommand({
        TableName: "Users",
        Item: { userId: user.id, name: user.name }
    });
    
    await docClient.send(command);
    return { statusCode: 200, body: "User created!" };
};

1. 4. The Gateway: You link API Gateway POST /users to this Lambda. You now have a fully serverless, infinitely scalable Create, Read, Update, Delete (CRUD) backend!

8. Real-World Scenarios #

9. Best Practices #

• Single Table Design: If you use DynamoDB, do not try to replicate SQL tables! In relational databases, you have a Users table and an Orders table, and you JOIN them. DynamoDB does not support JOINs. Advanced serverless developers use "Single Table Design," where Users and Orders are stored in the *exact same table* with clever Partition Keys to enable lightning-fast queries.

10. Cost Optimization Tips #

• Eventual Consistency: When reading data from DynamoDB, you can choose "Strongly Consistent" (guarantees the absolute latest data) or "Eventually Consistent" (might be a millisecond out of date). Eventually Consistent reads cost half the price. Use them whenever possible!

11. Exercises #

1. 1. Explain why traditional relational databases (like standard MySQL) often fail under the extreme scaling patterns of Serverless Functions.

1. 2. What is the fundamental financial difference between Provisioned Capacity and On-Demand Capacity in DynamoDB?

12. FAQs #

13. Interview Questions #

• Q: Describe the "Connection Pool Exhaustion" problem encountered when placing an AWS Lambda function in front of an Amazon RDS MySQL database. How does Amazon RDS Proxy resolve this issue?

• Q: Contrast the architectural implementation of a SQL JOIN operation with the data modeling strategy required in Amazon DynamoDB (Single Table Design).

14. Summary #

15. Next Chapter Recommendation #