Cloud Cartographer

The finding

At 100 concurrent users, the recorded PostgreSQL CPU P95 exceeded the backend's, while the monitoring stack also accounted for substantial CPU:

The load profile is very light. Each simulated user registers once, logs in once, then issues a single GET /api/session on a one-to-five second wait. The whole 100-user test generated about 6.8 MB of backend egress.

Measurement workflow

The harness runs headless Locust scenarios at 10, 50 and 100 users for 10, 10 and 15 minutes. It queries Prometheus over each run's exact time window with a 15-second step and computes percentiles in Python. Loki supplies log-query results.

When cAdvisor did not report the needed metrics in this setup, I tried a separate Ubuntu VM to investigate the environment, then used docker-stats-exporter as the replacement. The change provided a measurement path; it does not by itself validate every exported counter or explain the database anomaly.

What the numbers do that the report missed

The P95 across all three scenarios is 3.92, 3.94, 3.40 vCPU for 10, 50 and 100 users.

These observations do not show proportional CPU growth with the user count. That is a reason to investigate background work and the measurement path before using a linear extrapolation, not proof of a specific root cause.

The remaining hypotheses include database configuration, exporter artefacts and background maintenance such as autovacuum or checkpointing.

It also raises a question the report does not answer: if database CPU does not scale with load, what exactly was being sized by the linear ×10 extrapolation below?

Ruling two hypotheses out by reading the source

The original analysis listed four. Two were dismissed by inspecting the application rather than by inference:

• Missing index on users.email: the column is declared TEXT UNIQUE NOT NULL, which creates a unique index. The login and session lookup path is indexed.
• No connection pooling: sql.Open("pgx", ...) returns a persistent *sql.DB pool, and no SetMaxOpenConns override is set. One or two active connections does not, by itself, establish that a persistent pool is missing.

That leaves configuration, measurement, and background maintenance. The write-up states the conclusion plainly:

The root cause therefore remains unidentified.

The cost consequence

One database line is almost the entire bill. The concentration depends entirely on which total you divide by, so here are all four:

The database line is identical in both sources, so the only thing that changes is the denominator. It changes the answer by nearly two points on AWS. The project page previously claimed "over 92%" AWS and "over 90%" Azure. The first is true only against the export; the second is true of neither.

The totals do not reconcile

3-Migration-Cost-Analysis.md cites the calculator CSVs as its source, and its own columns add up correctly: $889.48 plus $8,530.68 is $9,420.16 exactly. But summing the CSV line items gives $9,240.09, so the document's platform subtotal is $180.07 higher than anything in the file it points at. Azure does the same at $82.33.

The gap is entirely in the platform figure. The database line matches to the cent in both clouds, so this is not rounding, and it is not a stale export. It is a subtotal that was never reconciled against its stated source. The document does acknowledge the discrepancy once, in a parenthesis, when computing the 92.3% figure against the calculator total. Everywhere else it uses $9,420.16.

An instance at $8,530.68/month, sized from a number nobody can yet explain.

The recorded decision was to size conservatively from that value and flag the uncertainty as the leading migration risk. This remains a planning assumption; diagnosing the anomaly is necessary before treating the sizing as validated.

The audit

The later review corrected several figures and separated projections from measured observations:

The egress unit error is the instructive one. A total of 0.0068 GB over a 15-minute test was treated as a per-second rate, multiplied by the seconds in a day, and labelled a month. The ×10 user scaling claimed in the sentence above was never applied. The corrected figure, ~196 GB/month at 1,000 users, remains a model assumption rather than measured monthly transfer.

The log-volume correction matters more, because it was silently wrong in the optimistic direction. Both the 50- and 100-user runs saturated at the query cap, so logs_per_minute was an artefact of each test's duration: 498/min over 10 minutes against 333/min over 15. The apparent drop under higher load was purely the longer window. The true 100-user volume is higher than reported.

What this stage does not claim

• That the anomaly was solved. It was not, and the documentation says so.
• That ~$2,104/month is a budget. It is a hypothesis contingent on tuning delivering an 8 vCPU database, which is contingent on a cause nobody has found.
• That 587 GB/month of egress. That figure is wrong and is corrected above.
• That the load was representative. It is a registration-and-login workflow, and the report says so rather than implying otherwise.