Plan your instance

STACKIT offers maximum flexibility in conjunction with MongoDB. However, technical limitations require certain restrictions. To avoid technical debt, downtimes and unwanted future migration, it is best practice to plan your MongoDB Flex instance in advance.

Plan your needs

Before selecting your MongoDB Flex instance size, you need to analyze your data patterns and requirements:

Data volume analysis

Start by estimating your current and projected data size. Consider document size, number of collections, and growth rate over the next 12-24 months. MongoDB Flex stores data in BSON format, which can be 10-15% larger than JSON, so factor this into your calculations. As a rule of thumb, calculate with a factor of 2 to 2.5 for data growth in the next two years.

Query patterns

Examine how your application interacts with the database. Frequent complex queries, aggregations, and index-heavy operations require more CPU and memory resources. Applications with high read-to-write ratios may benefit from different sizing strategies than write-heavy workloads. Also consider if your application is more read or write heavy.

Limitations

You can consult Architecture of MongoDB Flex for the limitations in flexibility. For a quick reference, you can consult this table:

Parameter	Downgrade possible	Upgrade possible	Downtime
type			not applicable
flavor	x	x	x
performance-class	x (except single-instance)	x (except single-instance)	x
storage-size		x
version		x	x

You can make changes to ACL and backup settings without any limitations and without downtime.

Best practices

You need to keep the limitations in mind. This paragraph helps you to make good assumptions and choices to set up an instance.

Instance type

If you plan to set up an instance for production use, you need to distinguish between a Replica and a Sharded instance type. For most cases Replica is the better option. In the following cases may consider using a Sharded instance:

Geographical sharding

• Compliance requirements (EU-users remain in the EU etc.)
• Data that needs to be accessed from several regions

Sharding due to high data size

• Single server storage limitations (multi-TB datasets)
• Working set doesn’t fit in RAM of single machine
• Index size exceeds single server capacity

Sharding for increasing performance

Read & write scalability: Distribute read and write on multiple servers (only possible when operations are independent from other shards)

Sharding (except geographical sharding) should be the last ressort, first try to achieve the goals with replica sets, indexing and vertical scaling.

Downsides of sharding:

• Adds complexity
• Decreases performance on queries which depend on multiple shards

Flavor

At first you need to distinguish if short downtimes are acceptable. If yes, you can start with a small flavor and upgrade it, when you consistently reach 80% of either CPU or RAM consumption. If downtime isn’t acceptable, you need to estimate your needs.

As a rule of thumb you may use this ruleset:

CPU

• Read-heavy: 2-4 CPUs sufficient
• Write-heavy or aggregations: 8+ CPUs
• Sharded clusters: Extra CPUs for mongos router

RAM

• Minimum: 25% of data size + index size
• Optimal: 50-75% of active data size + index size
• Rule of thumb: 8GB RAM at minimum, better 32GB+ for production

You can assume the index to be as big as 30% of your data size.

Performance class

For the performance class you need to distinguish as well if short downtimes are acceptable. If not, you need to estimate your needs.

As a rule of thumb, you may use this ruleset:

IOPS:

• Read-heavy: 1000-3000 IOPS
• Write-heavy: 3000-10000+ IOPS
• Mixed workload: 2000-5000 IOPS

Storage size

As storage size can be enlarged anytime without downtime, it is safe to start with a smaller size. As a rule of thumb, start with your data size multiplied by 1.3 for the index and multiplied by 3 again for the growth factor.

Version

Start with the highest version your client applications support.