Case Study 1 — Choosing Well: A Startup That Ran the Framework

A counter-example to the hype-driven disasters: a startup that resisted the urge to adopt trendy databases, ran the decision framework honestly, chose PostgreSQL, and added specialized stores only as concrete needs emerged. Years later, the architecture was simple, reliable, and exactly as complex as it needed to be.

Background

A new startup was building a logistics platform — shipments, carriers, customers, tracking, billing. The founding engineers had seen colleagues at other startups reach reflexively for MongoDB, microservices-with-a-database-each, and distributed systems "to be web-scale." They decided to make the database decision deliberately instead, running the framework (this chapter) against their actual requirements.

Running the framework

  • Data model: shipments, carriers, customers, and billing are deeply relational — entities with relationships, rules, and integrity (a shipment belongs to a customer, references a carrier, must balance against invoices). → relational.
  • Workload: OLTP — many small transactional operations (create shipment, update status, record payment). → relational, ACID.
  • Scale: at launch, hundreds of customers; honestly projected to thousands within two years. Comfortably one server. → no distribution needed.
  • Consistency: billing and shipment status need strong consistency (no lost payments, no wrong status). → ACID (CP), rules out eventually-consistent stores for the core.
  • Query patterns: rich and evolving — operational dashboards, ad-hoc support queries, reports. → full SQL.
  • Team/ops: a small team that knew SQL and could operate PostgreSQL (especially managed). → favor the familiar, operable choice.
  • Cost: open-source, free, managed cheaply on their cloud. → PostgreSQL.

Every factor pointed the same way. They chose managed PostgreSQL as the single system of record, and resisted adding anything else until a concrete need appeared.

Adding specialized stores — only as needed

Over the next two years, they extended the architecture deliberately, each addition justified by the framework:

  • Read load grew → they added read replicas (Chapter 35) for dashboards/reports. (Not sharding — the framework said scale didn't warrant it.)
  • Hot lookups (live tracking status hit constantly) → a Redis cache in front of PostgreSQL (Chapter 33), with PostgreSQL still the source of truth.
  • Geographic queries (carriers/depots near an address) → enabled PostGIS (Chapter 36) — an extension, not a new database.
  • An AI "similar past shipments" feature → pgvector (Chapter 36) — again an extension, embeddings stored beside the relational data.
  • Executive analytics over years of history → eventually a small columnar warehouse (Chapter 34), fed nightly by ELT, so analytics didn't compete with operations.

Notice: three of the five "specialized needs" were met by PostgreSQL extensions (PostGIS, pgvector, replicas), one by a complementary cache (Redis), and only the genuinely-different analytical workload got a separate system (the warehouse). The core stayed one well-understood PostgreSQL database. No MongoDB, no premature sharding, no microservice-database sprawl.

The outcome

Years in, the architecture was boringly reliable: one PostgreSQL system of record (with replicas and a couple of justified satellites), a small team that fully understood it, low operational burden, and no "re-architecture" crises. Competitors who'd reached for trendy distributed/NoSQL stacks were often fighting complexity, sync bugs, and operational fires the framework-driven team simply never had. Simplicity, chosen deliberately, was a durable competitive advantage.

The analysis

  1. The framework turns a guess into a decision. Running data-model/workload/scale/consistency/queries/ops/cost against actual requirements pointed clearly to PostgreSQL — and gave a reason for every choice, defensible in review and revisitable later.

  2. PostgreSQL as the deliberate default paid off. It fit the core perfectly and, via extensions, absorbed needs (geo, vector) that others solve with separate systems. One database, deeply understood, beat a zoo of specialized ones (theme #4).

  3. Polyglot, but minimal and justified. They did add Redis and a warehouse — but only when a concrete need (hot-key caching, analytics-vs-OLTP contention) appeared, and they kept PostgreSQL as the authoritative system of record. That's healthy polyglot persistence, not sprawl.

  4. Honest scale assessment prevented premature complexity. They didn't shard or distribute for traffic they didn't have (Chapter 35's lesson). Read replicas covered growth; the framework said that was enough, and it was.

  5. Simplicity is an advantage, not a compromise. The "boring" architecture freed the small team to build product instead of fighting infrastructure. Choosing the right-sized tool — and not over-engineering — is itself a skill, and a competitive one.

Discussion questions

  1. Run the framework factor-by-factor for this logistics platform — why does each point to PostgreSQL?
  2. Of the five specialized needs they later had, how many were met by PostgreSQL extensions vs. separate systems? What does that ratio illustrate?
  3. Why was Redis a justified addition, and why did PostgreSQL stay the system of record?
  4. Why didn't they shard, given two years of growth?
  5. ⭐ Contrast this with Case Study 2 (next): what single discipline separated the good outcome from the bad?