Lesson 2: The Standard Workload Profile

Why you profile before you pick

Level 1 gave you the full map of AWS databases. The map doesn't tell you which one to use. People who choose a database because a conference talk was good tend to regret it, and the regret usually arrives around month nine, when the data no longer fits on one node or the auditors ask for the RPO.

The fix is a standard workload profile. It is one short document that turns "we need a database" into numbers and constraints. Every service lesson in this course is judged against the same twelve fields, so you compare like with like. Think of it as a building survey. You measure the load-bearing walls before you look at kitchens.

The twelve fields

Two definitions trip people up:

• RPO (recovery point objective) is how much data you can afford to lose, measured in time. "RPO 5 minutes" means losing the last five minutes of writes is acceptable.
• RTO (recovery time objective) is how long you can be down before service returns.

Gotcha: use p99 latency, not the average. If the average is 4 ms and p99 is 300 ms, one request in a hundred is slow. A page that makes 50 database calls will hit that slow tail often.

Walkthrough: measure, don't guess

If the app already runs on PostgreSQL, take the numbers from the database itself rather than from memory:

-- 1. Transactions so far (counter since stats reset). Run twice, 60 s apart.
SELECT sum(xact_commit + xact_rollback) AS txns FROM pg_stat_database;
-- 10:00:00 -> 48,210,500
-- 10:01:00 -> 48,282,500   => (72,000 / 60 s) = 1,200 TPS at this moment

-- 2. Current size of each database
SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database;
-- shop | 412 GB

Take the samples at your peak hour, such as Monday 09:00 or a sale launch, and not at 3 a.m. Do the same for size: compare last month's backup sizes to get growth per month.

Worked example: the ShopLine order service

Here is a filled-in profile for a sample e-commerce order service. Keep it in the repo next to the code:

# workload-profile.yaml  (ShopLine orders, measured 2026-10)
data_model: relational          # orders, order_lines, customers, joins everywhere
read_write_mix: 80/20
qps: { average: 1200, peak: 6000 }   # peak = Black Friday, measured last year
latency_p99_ms: { read: 20, write: 50 }
transactions: multi-row ACID    # order + lines + stock decrement must commit together
consistency: strong on writes; reads of own order must be fresh
size_gb: 412
growth_gb_per_month: 25         # ~1.2 TB in 3 years
largest_record_kb: 6
scaling: single writer is fine; read replicas for catalogue browsing
availability: 99.95%
rpo: 1 minute                   # HARD - finance signed this
rto: 15 minutes                 # HARD
multi_region: DR copy in a second region; no active-active writes
engine: PostgreSQL 16, uses PostGIS   # HARD - store-locator depends on it
licensing: none needed (open source)
workload_type: OLTP; nightly reporting runs on a separate copy
team_skills: strong PostgreSQL, no DynamoDB experience   # SOFT
cost_model: steady base, 5x spike ~10 days/year; budget ceiling set

Read the comments. Each field is tagged HARD or SOFT.

Hard requirements vs soft preferences

A hard requirement knocks a service out on its own. No amount of good features elsewhere makes up for missing it. Typical hard requirements:

• Engine compatibility. 40,000 lines of PL/SQL means you need Oracle compatibility, or you budget for a rewrite.
• Licensing. Licence terms are a hard constraint. On RDS for Oracle, for example, the License Included model covers Standard Edition 2 only, so Enterprise Edition means bringing your own licence. RDS for Db2 offers your own licence or hourly IBM licensing through AWS Marketplace.
• RPO/RTO and compliance. These are signed by the business. You don't negotiate them in a design review.
• Record size. DynamoDB caps an item at 400 KB, and you can't raise that cap.

A soft preference carries weight in the comparison, but it can be traded away. Team familiarity is the classic example. Your team can learn a new service. They can't make PL/SQL run on a key-value store.

Best practice: ask "who signed this, and what happens if we miss it?" If the answer is a regulator, a contract or a large rewrite, the field is hard. If it is "we'd be slower for a quarter", it is soft.

Use the profile to rule out whole groups

Before comparing individual services, cross off whole groups from the Level 1 map using only the hard fields:

What's left is short enough to compare properly. Note one dated fact here: Timestream for LiveAnalytics has been closed to new customers since 20 June 2025. AWS points new customers to Timestream for InfluxDB, so "time series" is no longer a single option even when it does fit.

Trade-off: ruling out a group too early is also a mistake. If the peak QPS were 600,000 writes per second, "single writer is fine" would be false, and the key-value group would come back in.

Key takeaways

• The profile has twelve fields. Fill them with measured numbers: peak QPS, p99 latency, GB and GB/month, RPO and RTO in minutes.
• RPO is how much data you can lose. RTO is how long you can be down.
• Measure at peak, from the database itself. Don't size for the average.
• Tag every field HARD or SOFT. Engine compatibility, licensing, RPO/RTO and size limits are hard. Team familiarity is soft.
• Cross off whole database groups using the hard fields before you compare individual services.