6.1 · DB Design for a Startup: Keep It Simple
Concept. Most apps never outgrow one machine, so start with a managed single-node Postgres for its ACID guarantees, and when reads strain it, add read replicas long before you reach for sharding.
Intuition. Instagram rode Postgres to a billion-dollar exit and WhatsApp served 900 million users on it. A startup's real risk is corrupting its first users' data, not running out of scale. So ship on the simple, safe monolith; when reads pile up, copy the database into read replicas while the primary keeps taking every write.
The Structured Monolith (10 - 100 GB)
95% of data apps will never exceed a single node. Start with managed PostgreSQL. Optimize for product velocity over distributed complexity.
Start Simple: The Reality of Database Scale
PostgreSQL on AWS RDS/Cloud SQL/Azure will handle your first 10 million users.
Here's why: PostgreSQL offers ACID guarantees right out of the gate. ACID, Atomicity, Consistency, Isolation, Durability, ensures that your data remains intact, even if the system hiccups. Think of it as the financial equivalent of ensuring a bank transfer doesn't magically create or lose money during a system crash. For a startup, the real threat isn't scaling; it's screwing up the data of your initial users. A structured monolith acts as your safety net.
Examples
| Company | Exit Value | Database Strategy |
|---|---|---|
| $1B | PostgreSQL until acquisition | |
| $19B | PostgreSQL handled 900M users | |
| Notion | $10B valuation | Still on PostgreSQL + replicas |
| Stack Overflow | Still thriving | 4 SQL Servers, 1.3B pageviews/month |
| OpenAI (ChatGPT) | 800M weekly users | One primary Postgres + ~50 read replicas (2026) |
The First Scaling Move: Read Replicas
Most apps read far more than they write. When a single Postgres instance starts to strain, the first move is almost never sharding. It's adding read replicas: copies of the database that serve reads while the original, the primary, keeps taking every write.
Figure 1. Writes go to the single primary (blue); reads spread across N replicas (violet). The primary streams its changes to the replicas asynchronously (dashed), so a replica can trail the primary by milliseconds. You scale reads by adding replicas without touching the write path.
The tradeoff is replica lag. Replication is asynchronous, so a read served by a replica may miss a write that just committed on the primary. Usually that is fine (a slightly stale follower count). When it isn't (a user must see their own just-saved edit), route that specific read back to the primary, the "read-your-writes" exception. This single pattern carries an app well past 100K daily users before sharding is worth the complexity. As of 2026, OpenAI serves 800 million weekly ChatGPT users off one primary Postgres with roughly 50 read replicas: no sharding, one write node, proof that this one move scales far enough to build a very large product on.
Common Startup Mistakes to Avoid
Over-Engineering from Day One
Reaching for sharding, microservices, or "web-scale" NoSQL before you have users is a classic distraction. Start with one Postgres instance, ship the product, and let real load data tell you what to scale next.
DIY Database Management
Every hour spent on database ops is an hour not spent on your product. Use AWS RDS, Cloud SQL, or Azure Database. Period.
Next
SQL's Complex Types → Before you reach for anything bigger than one Postgres, see how much that single node already does: JSON, vectors, geo, even LLM calls, all in plain SQL.