In this chapter
We'll meet operational complexity, cost, team expertise, and managed vs. self-managed as real, human requirements — applied to GreenMart's own next expansion.
The Problem in Real Life
The technical requirements are real and specific now. Mike asks a question that has nothing to do with technology at all: who on GreenMart's own team actually has to keep this running at 2 a.m. when something breaks?
Sarah remembers Act 11 immediately — six or seven specialized databases had already made this exact question painfully real once. She's not going to let it happen by accident a second time.
Fine, but who actually has to run this thing once it's live?
Mike
The Best Database vs. The Database GreenMart Can Actually Run
Team expertise is a real requirement
The most technically correct database is a worse choice if nobody on the team can actually run it confidently.
Cost means the real total, not the sticker price
Infrastructure, storage, transfer, and engineering time to operate it all count — the same honest accounting Act 4's capacity chapter taught.
Operational Complexity, Cost & Team Expertise
A database that's technically perfect for the workload but that nobody on GreenMart's team can actually operate isn't a real answer — it's a future incident. This chapter names the honest, human side of the decision.
- On day-to-day difficulty. Operational complexity asks how much real, ongoing work a database demands to keep healthy — monitoring, tuning, capacity planning, upgrades. Act 11's consolidation story made this concrete: six or seven specialized databases, each excellent alone, became their own operational burden simply by existing together.
- On real money. Cost isn't just a license fee — it's infrastructure, storage, data transfer, and the real engineering time spent operating it, the same honest total-cost thinking Act 4's DynamoDB capacity-and-cost chapter first introduced.
- On who's actually available to run it. Team expertise asks a plain, unglamorous question: does GreenMart already have people who know this database well, or would adopting it mean a real learning curve, hiring, or ongoing reliance on outside consultants? The most "correct" database on paper is a genuinely worse choice than a slightly-less-perfect one GreenMart's team can actually run confidently.
- On who does the operating. Managed vs. self-managed asks whether a cloud provider runs the database for GreenMart (patching, scaling, backups handled for a real, ongoing price) or whether GreenMart's own team runs it themselves (more control, more real operational work). Act 4's DynamoDB and Act 9's managed vector databases are both real managed options; Act 5's Cassandra is commonly run self-managed.
For GreenMart's fleet-and-order requirement: GreenMart already runs DynamoDB in production (Act 4), the team has real, working expertise with it, and a managed option keeps operational complexity down during a period when the team is also busy shipping the expansion itself, not just running infrastructure. That's not a technical requirement — it's an equally real one.
Key Takeaway
The right database on paper and the right database for GreenMart aren't always the same thing — operational complexity, cost, and real team expertise are honest requirements too, not excuses for settling.
Why This Matters
Act 11 already showed what happens when this gets ignored: a technically sound choice made without weighing who actually has to run it, repeated enough times, becomes its own operational crisis. This chapter is what keeps that lesson in view before the next choice gets made, not after.
GreenMart now has a fourth real category of facts — how operationally demanding, how costly, and how well-matched to the team's real expertise the fleet-and-order requirement's options are. One category remains: the risks that don't show up until much later.