Plan your Key Value Store instance

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

Plan your needs

Before selecting your Key Value Store 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. Applications with high read-to-write ratios 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 Key Value Store for the limitations in flexibility. For a reference you can consult this table:

Parameter	Downgrade possible	Upgrade possible	Downtime
Type (Single/Replica)	-	-	-
vCPU	-	✓	✓
RAM	-	✓	✓
Disk	-	✓	✓

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

Please note that upgrading a single-node instance to a replica cluster is not supported. Because single instances are not intended for production environments, we strongly advise deploying a replica plan from the very beginning to ensure high availability for your productive workloads.

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. 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 replica cluster on multiple nodes.

Instance type

If you plan to set up an instance for production use, we strongly recommend a plan with 3 nodes (replica).

Plan

At first you need to distinguish if short downtimes are acceptable. If yes, you can start with a small plan 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, use this ruleset:

CPU

• Read-heavy: 1-2 CPUs sufficient
• Write-heavy or aggregations: 4+ CPUs

Memory

• Minimum: 125% of data size
• Optimal: 150%+ of active data size
• Rule of thumb: 4 GB RAM at minimum, better 8 GB for production

IOPS:

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

Key Value Store is an in-memory database. Therefore, the disk is only used for writing the persistence file.

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 multiplied by three again for the growth factor.

Version

Start with the highest version your client applications support. Be aware that even minor version differences prevent specific clients from connecting.