April 22, 2026
Pay‑per‑read, pay‑per‑rage
Nobody Got Fired for Uber's $8M Ledger Mistake?
Costly oops or normal growing pains? Commenters say no firings, just VC‑funded tuition
TLDR: Uber’s ledger spent big on a pay‑per‑use database, then got rebuilt—fueling debate over whether it was waste or normal scaling. Most commenters say don’t fire anyone; it worked, lessons were learned, and $8M is “VC‑funded tuition,” though some side‑eye the glowing case studies that followed.
Uber’s money-tracking system (a “ledger”) allegedly burned through about $8M after it was built on Amazon’s pay‑as‑you‑go database, DynamoDB, then rebuilt a few years later. Sounds juicy, right? The comments came in hot—and split. One camp says this isn’t scandal, it’s scaling: big companies try things, pay the bill, then move on. As [simonw] argues, firing people for an architecture that actually shipped and ran is “a terrible idea.” Another commenter doubled down, calling the piece a “submarine article” trying to sink a perfectly functional launch that was later optimized—and yes, promotions were earned.
Others went full meme mode: “$8M is a rounding error,” joked one, saying venture money basically underwrote a masterclass in what not to do. Meanwhile, skeptics poked the hero-worship around ByteByteGo’s praise, asking why a pricey detour became a “case study.” A curious side-thread asked how Spotify’s DynamoDB bet turned out, hinting this is a broader industry pattern.
For non‑tech folks: DynamoDB charges per read/write. Uber does millions of trips a day; each trip creates multiple records—cha‑ching. Uber later moved hot data to the fast store and old data to cheaper storage, then built its own LedgerStore. Was it a blunder or tuition? The crowd can’t agree—but they’re absolutely entertained.
Key Points
- •Uber launched a payments platform on Amazon DynamoDB in 2017 and later found the cost prohibitive at its scale.
- •DynamoDB’s consumption-based pricing (per read/write) became expensive given Uber’s volume (millions of trips, multiple ledger entries per trip).
- •Within about two years, Uber kept roughly 12 weeks of hot data in DynamoDB and moved older data to TerraBlob, with LSG considered as a long-term solution.
- •Uber migrated a trillion ledger entries from DynamoDB to LedgerStore, as documented in an Uber engineering blog post.
- •The article explains DynamoDB’s per-partition strong consistency within a Region and argues it suits global payment acceptance but is ill-suited as a ledger due to costs and consistency trade-offs.