Most Startups Don't Need a Sharded MongoDB Cluster

Let's talk about databases.

When startups start thinking about their database architecture, the conversation almost always jumps straight to scale. Should we shard MongoDB? Should we use Atlas? How do we handle billions of records? What happens when we hit millions of users?

These are important questions. They're just usually asked about three years too early.

The Setup

Recently, we worked with an early-stage startup evaluating their MongoDB architecture. The initial discussion moved quickly toward sharding, horizontal scalability, and managed database services. The founders had read about how large-scale companies distribute data across dozens of shards. They wanted that future-proof setup from day one.

After reviewing their actual workload, growth projections, and business requirements, we came to a different conclusion entirely:

They didn't need a sharded MongoDB cluster.

In fact, a simple replica set was more than enough.

The Problem With Planning for Hypothetical Scale

One of the most common mistakes we see is teams designing for the scale they hope to have someday instead of the scale they have today.

The result is almost always the same:

• More infrastructure to manage
• More operational complexity
• Higher monthly costs
• More things that can fail

And none of it solves an actual problem. It solves a hypothetical one.

Before discussing sharding with any client, we always start with one simple question: what problem are we actually trying to solve right now?

The Actual Workload

Before recommending any architecture, we wanted to understand exactly what we were designing for. Not what the startup hoped to handle in two years — what they were handling today.

At the time, the application was processing:

• ~40,000 monthly active users
• ~110 writes per second
• ~1,200 reads per second
• ~500 GB of total data

More importantly:

• CPU utilization was healthy
• Memory pressure wasn't a concern
• Query latency remained low
• Storage growth was predictable

We weren't hitting any bottleneck that justified the operational complexity of a sharded cluster. Not even close.

What a Replica Set Actually Gives You

For anyone unfamiliar with the distinction: a MongoDB Replica Set consists of one primary server handling writes and one or more secondary servers maintaining copies of the same data. It gives you high availability, automatic failover, read scalability, and data redundancy.

A Sharded Cluster, on the other hand, distributes data across multiple servers — each shard storing only a portion of the dataset. Its purpose is horizontal scaling when a single replica set can no longer handle the throughput or data volume.

Here's the thing most teams miss: for most startups, the immediate challenge is ensuring availability and reliability — not scaling horizontally. A replica set handles that beautifully.

At no point during our evaluation did we identify a bottleneck that required horizontal database scaling. Yet the team was ready to pay the complexity cost anyway — simply because they'd seen other companies do it.

The Atlas Question

Once we confirmed a replica set was sufficient, the next question became: should we use MongoDB Atlas or self-host?

Atlas is an excellent product. You get managed backups, automated upgrades, built-in monitoring, operational simplicity, and easy scaling. No argument there.

But those benefits come at a premium. And for an early-stage startup watching every dollar, that cost difference can easily translate into thousands of dollars per year.

The team was still early in their journey. Keeping infrastructure costs under control mattered more than outsourcing database operations to a managed service they didn't yet need.

Why We Went With a Replica Set on EC2

We weren't trying to build the cheapest solution. We were trying to build the simplest solution that satisfied the business requirements.

By running MongoDB Community Edition as a replica set on EC2, the client got:

• Lower infrastructure costs
• Full control over the environment
• Predictable pricing
• Sufficient scalability for current needs

Most importantly, we avoided solving problems that didn't exist yet.

The Tradeoffs We Accepted

Every infrastructure decision involves tradeoffs. By not choosing Atlas, we accepted responsibility for:

• Backups
• Monitoring
• Upgrades
• Maintenance
• Disaster recovery planning

These are all things Atlas handles extremely well. If the team had lacked infrastructure expertise — or didn't have us managing their infrastructure — our recommendation would likely have been different.

But they did have us. So the tradeoff made sense.

One Thing We'd Do Differently

Looking back, there's one decision we'd change if we were starting over.

We initially went with MongoDB Community Edition because it did everything needed at the time. Simple, worked well, cost nothing extra. A perfectly reasonable choice.

As the platform grew, audit logging became a requirement. That's when we discovered Community Edition doesn't include built-in audit logs.

If we were doing it again, we'd seriously consider Percona Server for MongoDB from day one. It ships with:

• Audit logging out of the box
• Better operational tooling
• PMM (Percona Monitoring and Management) integration
• Improved observability

The good news? Fixing this wasn't painful. Since Percona is compatible with MongoDB, the migration was mostly swapping binaries and performing rolling restarts across the replica set. The application stayed online the entire time.

Lesson learned: sometimes the infrastructure decisions you regret aren't the flashy architectural bets. They're the seemingly minor choices that look perfectly reasonable at the time but become limitations as compliance and operational requirements evolve.

The Bigger Lesson

This isn't really about MongoDB.

It's about how startups make infrastructure decisions.

We frequently see teams adopt sharded databases before they need them, enterprise tooling before it's justified, and managed services before the cost makes sense. The result is usually more complexity — not more value.

Infrastructure should evolve alongside the business. Not ahead of it.

Our Rule of Thumb

We consider sharding when:

• Data size becomes difficult to manage on a single replica set
• Write throughput becomes a genuine bottleneck
• Horizontal database scaling is actually required by the workload

Until then, we keep things simple. A well-designed replica set can take most startups much further than they expect.

The Takeaway

The goal isn't to build for the scale you hope to have someday. The goal is to build for the scale you have today — while leaving room to grow tomorrow.

For this startup, a sharded MongoDB cluster wasn't the answer. A replica set was.

And sometimes, the simplest architecture is the most scalable decision you can make.

Over-engineering your database? We'll tell you what you actually need. Book a free infrastructure review with SmartDevops — no commitments, just honest advice on what makes sense for your stage.