Plan your instance

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

Plan your needs

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

Data volume analysis

Start by estimating your current and projected data size. 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, joins, 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 MariaDB for the limitations in flexibility. For a quick reference, you can consult this table:

Parameter	Downgrade possible	Upgrade possible	Downtime
type (single/replica)			not applicable
vCPU		x	x
RAM		x	x
disk		x	x

You can make changes to ACL and disk threshold 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 when setting up an instance.

You set vertical and horizontal scaling with the available plans. A plan determines the number of vCPUs, the size of RAM and disk, and whether your instance runs on a single node or as a Galera Cluster on 3 nodes.

Instance type

If you plan to set up an instance for production use, we strongly recommend a plan with 3 nodes (replica). To learn more about high availability and STACKIT’s cluster implementation, read Cluster setup.

Flavor

At first, you need to distinguish if short downtimes are acceptable. If they are, 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

RAM

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

IOPS:

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

Storage size

If downtime is acceptable, then it is safe to start with a smaller disk size. As a rule of thumb, start with your data size and multiply by 3 again for the growth factor.

Version

Start with the highest version your client applications support.