Architect BeaconSign in

The ladderRung 2 of 8

Rung 2 — Managed database + live app

One line: Many people write, one place holds the truth, and something checks the data on the way in.

1. Concept

You leave Rung 1 because the single-writer assumption broke. Two people at two counters, an online store and a physical one, a customer who wants to see their order — all of them need to write to the same facts at the same time without stepping on each other. A spreadsheet cannot do that. A database can.

What this stage is for: one source of truth that enforces its own rules (a database), and one application in front of it so nobody types directly into tables. The database says "an order must belong to a customer" and refuses anything else. The app gives staff and customers a screen instead of a grid.

"Managed" is the important word. At this rung you rent the database from a provider who runs it, backs it up, and patches it. You do not install Postgres on a server you own. Every hour you spend running a database is an hour not spent on the business, and you will run it worse than the provider does.

"Live app" means one deployable application — a monolith. That is not a compromise; it is the correct shape for one team. Splitting into services is a Rung 3 problem, and doing it early is the most common self-inflicted wound on the ladder.

For students: this rung is where you learn the relational model for real (tables, keys, constraints, migrations), how an app talks to a database safely, and what "production" means — backups, environments, a deploy that can be rolled back.

2. Signs you are here

In business language

  • Staff at more than one counter or location enter orders into the same system.
  • Customers have accounts, or you take orders online and in person.
  • There is a "system" people log in to, and it has a URL.
  • Arguments about "which number is right" have stopped, because there is only one.
  • When the app is down, the business is down. You feel it.

In technical language

  • A single managed relational database (Postgres or MySQL) is the source of truth.
  • One application codebase, deployed as one unit, talks to it.
  • Automated backups exist because the provider does them. Restores are untested.
  • Auth is handled by the app or a provider (Supabase Auth, Auth0, Clerk).
  • Reports are SQL run by hand against the production database, usually at night.

3. The decision

Four forks show up at Rung 2. Three of them have a default answer; only the first needs real thought.

Fork 1 — Buy the app or build it? If your business is commodity retail, restaurant, booking, or subscriptions, a platform (Shopify, Square, Toast, Stripe Billing, Calendly) is your Rung 2. Their database is your managed database; their admin is your app. Build only the piece that makes you different, and hang it off their API.

Build the whole thing when the workflow is the business — nobody sells your process off the shelf — or when the platform's fees exceed what a developer costs.

Fork 2 — Managed or self-hosted database? Managed. Always, at this rung.

Fork 3 — Relational or document/NoSQL? Relational unless you have a specific reason. Orders, customers, products, and money are relational data. "We might need to scale" is not a reason at this rung.

Fork 4 — Monolith or services? Monolith. One codebase, one deploy. Revisit at Rung 3 when you have more than one team.

How to choose on Fork 1: list the screens the business needs. If more than two-thirds exist in a platform you can rent, rent it. Build the rest.

[k3r war-story slot: the concurrent-write collision — what it looked like from the counter and what it looked like in the data]

4. Tools

Categories first. Affiliate disclosure: links marked (affiliate) may pay us a commission. It never changes the recommendation.

Managed relational database

  • Supabase — Postgres plus auth, storage, and row-level security in one place; fits a small team that wants the fewest moving parts. Free tier launches most Rung 2 apps.
  • Neon — serverless Postgres with branching; fits when you want dev/staging databases that cost nothing when idle.
  • Amazon RDS / Google Cloud SQL — fits when the business is already on that cloud or compliance needs the big-cloud paperwork. More knobs, more cost.
  • PlanetScale — managed MySQL with strong migration tooling; fits MySQL shops.

Backend-as-a-service (database + auth + storage together)

  • Supabase — relational; the default recommendation here.
  • Firebase — document model; fits mobile-first apps with simple data. Painful for reporting later.

Application framework (pick the one your developer knows)

  • Next.js (TypeScript) — one codebase for UI and API; deploys to Vercel in minutes.
  • Rails, Django, Laravel — batteries-included monoliths with 15+ years of "how do I do X" answers. Excellent Rung 2 choices.

Hosting

  • Vercel — fits Next.js; zero ops.
  • Render / Railway / Fly.io — fits Rails/Django/Laravel; a container with a database next to it, still zero ops.

Internal tools (staff screens without building them)

  • Retool, Appsmith — a table editor and forms on top of your database for staff; saves weeks of admin-screen work.

Payments — Stripe, Square: never store card data yourself.

Uptime and errors — UptimeRobot / Better Stack (is it up?), Sentry (what broke?).

5. Next trigger

The ladder forks after Rung 2. Most small businesses go 2 → 4 (analytics) and never need Rung 3 (services). Rung 3 is triggered by team shape, Rung 4 by reporting pain. Watch for both.

Toward Rung 3 (containers + services)

  • Business: more than one team ships features; releases wait on each other; a change in one area breaks another and nobody expected it.
  • Technical: one deploy for everything; the build takes long enough that people batch changes; one slow module drags down the whole app.

Toward Rung 4 (first analytics)

  • Business: "how did we do this week?" takes someone a day; the owner wants a dashboard; the app gets slow at month-end when reports run.
  • Technical: reporting SQL runs against the production database; long queries lock or slow writes; someone has built a second spreadsheet from the database.

Signs the database itself is straining (address before either move)

  • Connection limits hit under load; queries that were instant take seconds; the free tier is the ceiling and the upgrade jump is large.

Threads

Security

  • The database is not reachable from the internet. Only the app (and you, via the provider's console or a tunnel) can connect.
  • Secrets (database URL, API keys) live in environment variables, never in code, never in the repo.
  • Least privilege: the app connects as a user that can read/write tables, not as the superuser. Staff roles are enforced in the app or by row-level security (RLS).
  • TLS everywhere. Providers default to it; do not turn it off.
  • Backups exist automatically; restore one to a scratch database once so you know the procedure works. Untested backups are a hope, not a backup.

Compliance placement

  • PCI — still outsourced. Stripe/Square hold the card; you store a token and the last four digits at most.
  • GDPR / CCPA — you now have a real personal-data inventory: which tables hold names, emails, addresses. Build one "export my data" and one "delete my data" path in the app now, while it is one table join, not twenty.
  • HIPAA — if health data enters the system, choose a provider that signs a BAA (Supabase, AWS, GCP do on paid tiers), encrypt at rest (default), and log access. This is the rung where HIPAA becomes yours to own.
  • SOC 2 — not yet, but the habits start here: version control, access logs, no shared admin accounts. A future auditor will ask for a year of history.

Data modeling

  • Third normal form by default: every fact stored once, referenced by key everywhere else.
  • Every table: an ID (primary key), created_at, updated_at. Money in integer cents, never floats. Timestamps in UTC.
  • Foreign keys enforced by the database, not by the app's good intentions.
  • Soft deletes (deleted_at) for anything a customer or auditor might ask about later.
  • Migrations are versioned and in the repo. The schema changes only through them. This is the single habit that makes Rung 4 possible.
  • Index what you filter and join on. Nothing else, yet.

Cost

  • $0–100/month for most Rung 2 businesses. Free tiers cover the launch.
  • The first surprising bill is usually storage and egress for uploaded images, or a per-seat internal-tools license. The second is the jump from free to paid database tier when connections or storage cross a line.
  • The hidden cost is the developer. Buying the platform (Fork 1) is often cheaper than one month of build time — do that math honestly.
Kept on this device. Sign in to keep it everywhere.
Review my stack against this rung