Vadym Kazulkin
Introduction
In the part 7 of the series Data API for Amazon Aurora Serverless v2 with AWS SDK for Java - Data API meets SnapStart we measured the cold and warm start times of the Lambda function connecting to the Amazon Aurora Serverless v2 PostgreSQL database using Data API for 3 use cases :
- without SnapStart enabled on the Lambda function
- with SnapStart enabled on the Lambda function but without priming optimization
- with SnapStart enabled on the Lambda function and with priming optimization (pre-warming SQL statement execution on the PostgreSQL database).
In this article we'd like to compare those measurements with those but with using DynamoDB instead of Data API for Amazon Aurora Serverless v2.
Comparing Lambda cold and warm starts: Data API for Amazon Aurora Serverless v2 vs DynamoDB
In my article series about Lambda SnapStart we've already done such measurements for the similar application but in the article Measuring warm starts with Java 21 using different Lambda memory settings .
Both applications Data API for Amazon Aurora Serverless v2 and DynamoDB are very similar :
- They provide logic to store and retrieve products from the database
- Lambda functions from both projects have 1024 MB memory setting
- The deployment artifact sizes are around 18 MB for both
- Lambda functions from both projects use default synchronous HTTP Apache client to communicate with databases
- Lambda functions from both projects use x86_64 architecture
Now lets put all measurements together.
Cold (c) and warm (m) start time in ms:
| Approach | c p50 | c p75 | c p90 | c p99 | c p99.9 | c max | w p50 | w p75 | w p90 | w p99 | w p99.9 | w max |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Data API, no SnapStart enabled | 3154.35 | 3237 | 3284.91 | 3581.49 | 3702.12 | 3764.92 | 104.68 | 173.96 | 271.32 | 572.11 | 1482.89 | 2179.7 |
| DynamoDB, no SnapStart enabled | 3157.6 | 3213.85 | 3270.8 | 3428.2 | 3601.12 | 3725.02 | 5.77 | 6.50 | 7.81 | 20.65 | 90.20 | 1423.63 |
| Data API, SnapStart enabled without priming | 1856.11 | 1994.61 | 2467.83 | 3229.11 | 3238.80 | 3241.75 | 61.02 | 113.32 | 185.37 | 639.35 | 1973.30 | 2878.5 |
| DynamoDB, SnapStart enabled without priming | 1626.69 | 1741.10 | 2040.99 | 2219.75 | 2319.54 | 2321.64 | 5.64 | 6.41 | 7.87 | 21.40 | 99.81 | 1355.09 |
| Data API, SnapStart enabled with priming | 990.84 | 1069.04 | 1634.84 | 2120.00 | 2285.03 | 2286.9 | 60.06 | 106.35 | 185.37 | 581.27 | 1605.37 | 2658.24 |
| DynamoDB, SnapStart enabled with priming | 702.55 | 759.52 | 1038.50 | 1169.66 | 1179.05 | 1179.36 | 5.73 | 6.51 | 7.87 | 21.75 | 92.19 | 328.41 |
Conclusion
In this article I compared measurements of the cold and warm start times of the Lambda function connecting to the Amazon Aurora Serverless v2 PostgreSQL database using Data API vs connecting to DynamoDB database for 3 use cases:
- without SnapStart enabled on the Lambda function
- with SnapStart enabled on the Lambda function but without priming optimization
- with SnapStart enabled on the Lambda function and with priming of the database request
What we observed is that cold start times without enabling SnapStart on the Lambda function are quite comparable for both. In case SnapStart is enabled (without and especially with priming) the Data API for Amazon Aurora Serverless v2 has significantly higher cold start times, especially for the percentiles >= 90. I will need to dig deeper to understand this difference as I didn't expect it to be that big, especially if priming was applied. Maybe the reason for that is that AWS native services like DynamoDB are more SnapStart-aware I can deal better with connection resumes.
The warm start (execution) times were constantly much higher for Data API for Amazon Aurora Serverless v2 comparing to DynamoDB which I also expected as DynamoDB is known for its single- or double-digit milliseconds response times.
