Plan your instance
STACKIT offers maximum flexibility in conjunction with PostgreSQL. However, technical limitations require certain restrictions. To avoid technical debt, downtimes and unwanted future migration, it is best practice to plan your PostgreSQL Flex instance in advance.
Plan your needs
Section titled “Plan your needs”Before selecting your PostgreSQL instance size, you need to analyze your data patterns and requirements:
Data volume analysis
Section titled “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. As a rule of thumb, calculate with a factor of 2 to 2.5 for data growth in the next two years.
Query patterns
Section titled “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 whether your application is more read-heavy or write-heavy.
Limitations
Section titled “Limitations”Consult Architecture of PostgreSQL Flex for the limitations in flexibility. For a quick reference, consult this table:
| Parameter | Downgrade possible | Upgrade possible | Downtime |
|---|---|---|---|
| type | x | x | x |
| flavor | x | x | x |
| performance-class | x | ||
| storage-size | x | ||
| version | x | x |
You can make changes to ACL and backup settings without any limitations and without downtime.
Best practices
Section titled “Best practices”Keep the limitations in mind. This section helps you to make good assumptions and choices to set up an instance:
Instance type
Section titled “Instance type”If you plan to set up an instance for production use, choose the 3 Replicas instance type.
Flavor
Section titled “Flavor”At first, you need to distinguish whether 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:
- Read-heavy: 2-4 CPUs sufficient
- Write-heavy, many joins or complex functions: 8+ CPUs
- Minimum: 25% of data size
- Optimal: 50-75% of active data size
- Rule of thumb: 8GB RAM at minimum, better 32GB+ for production
Performance class
Section titled “Performance class”Because the performance class can not be changed afterwards, you need to plan your needs before creating an instance. It might be a good idea to start with a developer/staging instance first to determine which performance class will be sufficient for your needs.
As a rule of thumb, you may use the following ruleset:
- Read-heavy: 1000-3000 IOPS
- Write-heavy: 3000-10000+ IOPS
- Mixed workload: 2000-5000 IOPS
Storage size
Section titled “Storage size”Storage size can be enlarged anytime without downtime, so it’s safe to start with a smaller size. As a rule of thumb, start with your data size multiplied by 3 for the growth factor.
Version
Section titled “Version”Start with the highest version your client applications support.