The Database Bet That Costs You Your Scaling Plans

You ship on Postgres because the engineer who set things up knew it. Then Series A happens.

Suddenly you’re at 100k transactions a day. Your queries that ran in 50ms now timeout. Your DevOps person is on pages at 2 AM debugging connection pools. You can’t shard. You can’t easily cache. You built half your system assuming your database could handle your entire query pattern, and you were wrong.

This happens because the database choice gets made too early - before anyone knows what the product actually needs - and then it’s too late to change.

The hard part is that database decisions don’t feel urgent until they’re already wrong.

Why This Happens

Most startups make their database choice for the right reasons - it’s solid, it’s boring, it’s what the engineer knows - and those are actually good reasons. Postgres is the right default database for most early-stage companies. MySQL works fine. MongoDB works if you actually have document-shaped data.

The mistake isn’t choosing the database. The mistake is assuming the choice you made for a $10k MRR company still works for a $500k MRR company. It often doesn’t.

Here’s what I see in practice:

You optimized for development speed, not production scale. Your early schema was designed for “get it out the door.” You had no indexes because you had no data. You normalized everything because you didn’t know what queries would matter. Then the product found product-market fit, and suddenly the database is the bottleneck that nobody planned for.

You didn’t account for your actual access patterns. When you started, you thought you’d query it one way. Turns out product, support, and finance all need different queries of the same data. You’re running reports that scan the entire table. Your search feature does full-text queries across millions of records. The database choice that was fine for transactional data is now choking on analytics.

You can’t easily move off it without rebuilding. This is the insidious part. By the time the database is causing problems, you have millions of rows, years of business logic around that schema, and the engineering team is familiar with it. You can’t just migrate to MongoDB or switch to a different engine without months of work and business risk.

The founder doesn’t see this coming because it’s technical. The CTO sees it coming but by then the decision is already made. And nobody thinks to ask: “What happens to this choice when we’re 10x bigger?”

What Usually Goes Wrong (In Order)

First, query performance. This is the most obvious problem and the first thing that gets expensive to fix. You’re running queries that join three tables and pull back thousands of rows. You add indexes. Indexes help, but they don’t fix the underlying problem - your query pattern doesn’t match your schema design.

At this point, you hire someone senior to optimize the database. They spend two weeks writing better queries. Performance improves by 30%. Relief lasts two months. Then the data grows again.

Then, scaling becomes architectural. You can’t just add more memory to the server. You need replication for failover. You need read replicas to offload reporting queries. You need to think about sharding or partition strategies. These are expensive changes that require architectural decisions you never planned for.

If you chose a database that’s hard to replicate or shard, you’re in trouble. MySQL replication has lag. Postgres sharding requires application-level routing. Document databases like MongoDB handle sharding better, but they have their own scaling problems (transactions, consistency guarantees, storage efficiency).

Finally, operations complexity. Scaling the database means ops work. Backups. Point-in-time recovery. Monitoring. Connection pooling. Cache invalidation. These aren’t glamorous problems, but they’re expensive in engineering time.

A lean team should not be spending engineering cycles on database operations. That should be solved by the database choice, not created by it.

The Framework That Actually Works

Here’s how I think through database choices with clients:

What’s your actual query pattern? Not what you think it will be. What is it actually doing right now? Are you mostly doing transactional reads and writes (OLTP)? Or are you pulling reports and doing analytics (OLAP)? Those require different databases.

This is the question most startups skip. They assume the database will be fine for “everything,” and that’s where it breaks. Your main application database (OLTP) and your reporting database (OLAP) should often be different things. Get that wrong, and you’re asking a relational database to do analytics work it’s not designed for.

What’s your data shape? Are your records mostly fixed schemas (user, order, product) or do you have varying structures? Relational databases win if your data is structured. Document databases win if you have semi-structured data or you don’t yet know your schema.

If you’re early and don’t know your schema yet, a document database gives you flexibility. But you’ll pay for it later in consistency and query performance. It’s a tradeoff, not a free win.

Can you handle operational complexity? This is the question nobody asks. A simple, boring database like Postgres is simple and boring to operate. A more complex database like MongoDB or Cassandra gives you different scaling characteristics, but they’re harder to operate.

For a team without a dedicated DevOps person, this matters. A lot. Postgres with a managed database service (RDS, etc.) is much easier to operate than Cassandra, even if Cassandra scales better.

What’s your growth curve? Are you expecting 10x growth in the next year? Or are you expecting steady, predictable growth? Growth curve determines how soon the scaling problems matter.

If you’re expecting 10x growth, you need to think about sharding or partitioning strategies now. If you’re expecting steady growth, you can often get away with a simpler database for longer.

What can you migrate if you’re wrong? This is the pragmatic question. If you’re wrong, how expensive is it to change databases? If you’re using a boring, standard database like Postgres, migration is painful but possible. If you’ve built your entire application around MongoDB’s document model, migration is incredibly expensive.

This is actually an argument for “boring” databases early. You can always add complexity later if you need it. It’s much harder to remove it.

The Real Decision Framework

For most startups, this is the right default:

Early stage (pre-Series A): Postgres or MySQL with a managed database service. Simple, boring, scales reasonably far, easy to operate. You’re optimizing for “will this work” and “can we operate this,” not for extreme scale.

Series A (product-market fit, 10-100k users): Still Postgres. By this point you know your query patterns. You’re starting to feel the pain points. You can optimize schema, add indexes, and implement read replicas. Most operational problems get solved by proper DevOps, not by database choice.

Series B and beyond (100k+ users, complex operations): This is where you might consider sharding, document databases for specific use cases, or OLAP databases for analytics. But by now you have the headcount to support operational complexity, and you know exactly which problems the database needs to solve.

The mistake is jumping to “complex database for scale” at Series A. You don’t have the operational maturity yet.

One More Thing That Actually Matters

Most of the database problems I see aren’t actually about the database choice. They’re about the queries.

Well-written queries on Postgres will out-perform badly-written queries on MongoDB. Proper indexing strategy matters more than database choice. Schema design matters more than database choice.

The database choice matters when you get to extreme scale or when your use case is fundamentally different from what the database was designed for (like running OLAP queries on an OLTP database).

Before you worry about sharding or migrating databases, worry about whether your queries are correct.

How to Make the Decision

Ask your team (or your fractional CTO, if you have one):

1. What are our main database queries doing? (Transactions? Reporting? Both?)
2. What does our data actually look like? (Structured? Semi-structured?)
3. What scale are we targeting in the next 18 months?
4. How much operational complexity can we support?
5. If we’re wrong, how much would it cost to move?

These five questions will point you toward the right database for your stage. Not the database that could scale to billion-user scale, but the database that makes sense for where you actually are right now.

The database choice is a business decision disguised as a technical decision. Get it wrong early, and you’ll be paying for it in engineering time, operations complexity, and scaling headaches for years.

Get it right, and you won’t think about your database at all. Which is exactly how it should be.