MongoDB: The Zerg Approach Database Scaling

Updated November 01, 2026

MongoDB scales horizontally. Instead of buying one bigger server (vertical scaling, or scaling up), you add more servers and spread the data and load across them (horizontal scaling, or scaling out). MongoDB does this with sharding, which splits a collection’s data across multiple servers, and replica sets, which keep copies of the data so another server can take over if one goes down. Here’s how the two approaches compare, and why I think of MongoDB’s as the Zerg approach.

Maybe you’ve heard the phrase “Data is the new oil.”

Data is big business and with it come challenges to take that crude data and refine it so that it can be used in a number of highly valuable ways—similar to oil.

One of the biggest challenges is being able to scale databases as the volume of data grows. It must handle increasing loads of requests, deliver the data quickly, and be reliably available.

So what exactly does it mean to scale a database?

It reminds me of the original Starcraft PC game. If you are not familiar with it, don’t worry about that, I’ll explain in a moment.

Scaling is two things:

Handling more data
Handling more concurrent users

And there are 2 primary ways to do this:

Vertical scaling
Horizontal scaling

Vertical scaling is the job of adding more resources to an existing server—more RAM, more hard drives, faster CPUs. Make the single machine better. You may have heard it said scaling up—that’s what this is.

Horizontal scaling is the job of just throwing more machines at the problem. As you know, my IT people, this is distribution. And this is called scaling out—sideways if you may.

Vertical Scaling: Pros and Limits of Scaling Up

This is the traditional approach and it has its advantages:

It’s simple. You just add/upgrade the hardware in the machine. There’s no need to change architecture or distribute data.
The results are immediate. Anything leveraging that server will now run faster.
The underlying structure of the database is still exactly the same, so no changes to application logic are required.

BUT…

There’s only so much room on a single motherboard to add hardware. There’s a ceiling to how much you can upgrade a single system.

If you want to max the components in a machine, you gotta pay. The high-end stuff isn’t cheap.

AND, you have to take the server down to upgrade it. That’s not really convenient.

Horizontal Scaling: Adding More Machines to Scale Out

The main advantage to horizontal scaling is that you can simply buy more computers and have them run together in a single system.

Most of the time, spending the same amount of money on multiple, less powerful machines will perform better than the same amount of money spent on one or two UBER machines.

After all, this is the foundation of what cloud service providers do.

Have You Heard Of ‘Zerging’ Something?

“What’s this have to do with Starcraft?” you might be wondering.

The purpose of the game was to build up an army and destroy your opponent. Each match would last anywhere between 5 minutes and several hours and there were 3 factions you could play as: The Terran (humans), The Protoss (alien) and The Zerg (Bug aliens).

One of the most effective approaches of the Zerg was to obtain a LOT of weak creatures for the same resource cost as 1-2 soldiers that the other factions had to spend and then you could overwhelm your opponent—with more numbers.

That’s what it means to Zerg something (and usually quickly).

Horizontal scaling is a bit like the Zerg: throw more servers into the mix in order to scale.

I could have used the tried-and-true metaphor of highway lanes (one super fast lane vs 20 lanes), but that wasn’t as fun.

Back To Reality: How MongoDB Scales Horizontally

The main drawback, however, is that running applications and managing data across multiple computers can get complex. Your software needs to support it.

MongoDB was built for horizontal scaling. Its architecture is designed to handle data distribution natively without compromising performance or reliability.

Sharding is a notable feature of MongoDB. It distributes data across multiple servers, ensuring that each shard (or partition) holds a subset of the data. This allows for load distribution and ensures that if one server gets Zerged by say a DDoS attack and goes offline, the entire system doesn’t come to a halt.

MongoDB also uses replica sets, which maintain multiple copies of data. If one server goes down, another can take its place without interruption.

The bottom line is that MongoDB was built for the Zerg approach.

Relational Database Management Systems (RDBMS) like SQL have come a long way to support horizontal scaling, but without getting into the nitty gritty and with the caveat that this isn’t always the case—their approaches tend to be more manual, tend to have steeper trade-offs, and tend to require changes to the applications running on them.

Considerations In Horizontal Database Scaling: Consistency vs. Availability

When horizontal scaling, there’s a tension between maintaining data consistency/correctness and maintaining data availability. You want the data to be consistent while at the same time you want the data to be available and it can be challenging to strike the right balance.

MongoDB leans towards availability, which means there might be moments when the data that gets read is out of sync across different nodes (computers), though it eventually syncs up.

SQL often employs a technique called two-phase commits to maintain strict consistency at all times. This introduces additional complexity and performance overhead.

When it comes to latency, MongoDB handles it natively with built-in mechanisms while SQL often needs third-party tools like load balancers.

And the big one is with sharding. MongoDB does it dynamically, but that doesn’t mean you can ignore a sharding strategy. With SQL, it almost always requires changes to application logic and is a manual process.

GG: Choosing SQL or MongoDB for Scale

“Good game,” let’s wrap things up.

The type of database you choose will be based on a number of factors.

There are many use-cases where consistency at all times is necessary and if that is a high priority, that data begins in a valid state and ends in a valid state after a write, read, whatever, at all times, then SQL will make more sense.

If speed and scaling are a priority, then a NoSQL database that natively handles horizontal scaling will shine.

What This Means If You Run Form.io on MongoDB

Form.io stores its forms and submissions in MongoDB, so this is the scaling model your form data lives on. A few practical points:

MongoDB or an equivalent is required. Supported options include MongoDB Atlas, AWS DocumentDB, Azure Cosmos DB, and MongoDB Enterprise Advanced for on-premise deployments. Submission data can also be sent on to other databases.
Use replica sets in production. Form.io uses MongoDB transactions in some operations, and transactions require a replica set. A single MongoDB instance works for development but will fail in production scenarios that trigger transaction logic.
Pick who handles the Zerg. MongoDB Atlas handles replication, backups, scaling, and maintenance for you. Self-managed MongoDB gives you full control, and your team handles installation, replication, and backups.
Run MongoDB 5.0 or later to stay compatible with all Form.io features.
Plan storage on submission volume. Form schemas are small (typically under 100KB each), and a 50-field text form produces submissions of around 5-10KB. Volume and retention drive your storage needs.

A few MongoDB details have also moved on since this post was first written in 2023:

Reads go to the primary by default. Only reads you route to secondaries (a non-primary read preference) can return stale data, because secondaries replicate from the primary asynchronously.
Writes default to majority acknowledgment. The default global write concern is “majority,” meaning a majority of the voting replica set members have durably written the change before it is acknowledged.
Multi-document ACID transactions are supported on replica sets and sharded clusters, for the cases where you need atomic changes across several documents.
The balancer moves data for you, but the shard key still matters. A background balancer migrates data between shards to even them out. A poor shard key can still cause uneven distribution, and you can reshard a collection to change it.

Sources: Form.io’s How It Works and Why Form.io Requires the MongoDB Document Model; MongoDB’s docs on sharding, replication, read preference, write concern, transactions, the balancer, and resharding. Keep reading: Model Data In A Schema-Less Data Environment With No-Code, Building An Application With A Drag And Drop Database, and Form.io Partner: MongoDB. Want to try it? Start a free 30-day trial or contact us.