6.1 · DB Design for a Startup: Keep It Simple
Concept. Most apps stay within one machine. Start with a managed single-node Postgres for ACID guarantees. Add read replicas when read load saturates the primary. Reach for sharding after replicas.
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.
Postgres gives you ACID (Atomicity, Consistency, Isolation, Durability): a crash part-way through a transaction leaves the data as though the transaction never ran, so a bank transfer cannot create or lose money on the way. For a startup the risk is rarely running out of scale. It is corrupting the data of your first users, and that is the risk ACID removes.
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. Add replicas to increase read capacity without changing 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.