Unit 7.3: Performance Engineering

Introduction

Performance on IONOS Cloud is engineered at design time, not tuned after the fact. The platform exposes a small number of decisions that dominate end-to-end latency and throughput: which storage tier a volume sits on and how large it is, whether a database tier is fronted by a pooler and a cache, and where each tier lands on the layered network path you established in Unit 1.2. Get these right and the architecture performs predictably under load; get them wrong and no amount of later tuning recovers the lost headroom.

This unit synthesises decisions made across earlier modules into a single performance view. It assumes the compute classes from Unit 4.1, the block storage tiers from Unit 4.2 and 5.1, the no-read-replica pattern from Unit 5.3, the cache tier from Unit 5.5, and the load balancers from Units 3.3 and 3.4. FinCorp's regulated transaction platform anchors the worked decisions.

1. Storage Performance Floors and Tier Selection

Block Storage on IONOS is an iSCSI block device available as HDD, SSD Standard, and SSD Premium. The selection criterion is rarely capacity, since all three tiers reach the same 4 TB maximum per volume. The criterion is the performance profile, and the two SSD tiers behave very differently from HDD.

HDD performance is static and independent of volume size: every HDD volume delivers the same 200 MB/s sequential read/write at a 1 MB block size and 1,100 IOPS at 4 KB (bursting higher). A 50 GB HDD volume and a 2 TB HDD volume perform identically. This makes HDD predictable but flat, suitable for sequential bulk and archival access rather than transactional databases.

SSD performance is the opposite: it scales with volume size up to a cap. The following table is the platform's documented SSD performance profile.

Because SSD throughput and IOPS accrue per gigabyte, a small SSD volume starves a demanding workload. The platform recommends booking SSD volumes of at least 100 GB to obtain the full benefit of high-speed SSD; smaller volumes are permitted but perform suboptimally. For database workloads this 100 GB floor is the load-bearing rule: an SSD volume below roughly 100 GB will degrade a database tier even when its data set is tiny. The performance the Data Center Designer predicts for a volume is derived from its size, and for SSD it is capped once the volume exceeds 600 GB, at the per-VM ceilings of 45,000 read IOPS and 600 MB/s sequential throughput for SSD Premium.

The design consequence is direct. You size a database SSD volume for performance first and capacity second. FinCorp's transaction database holds only a few tens of gigabytes of live data, but provisioning it on a 40 GB SSD volume would sit below the performance floor and throttle the very tier that carries the firm's regulated workload. The volume is therefore provisioned at or above 100 GB regardless of the data footprint, and on SSD Premium so that the per-GB IOPS allocation is doubled relative to SSD Standard. The bulk audit archive, by contrast, is sequential and cost-sensitive, so it lands on HDD where size does not affect performance, or on Object Storage entirely.

2. Throughput Levers: Pooling, Caching, and Node Ceilings

Once storage is correctly tiered, the next performance question is concurrency, and here the platform's honest boundaries shape the design. Managed PostgreSQL and MariaDB have no read replicas (Unit 5.3). You cannot scale reads by adding replica endpoints, so the throughput levers are connection pooling and caching.

The connection ceiling is not a tuning knob. PostgreSQL's max_connections is calculated from cluster RAM and is not user-configurable, ranging from 384 connections at 4 GB RAM up to a hard ceiling of 1,000 connections above 8 GB, with 11 connections reserved for internal superuser and replication use. An application tier that opens a fresh connection per request will exhaust this ceiling long before it exhausts CPU. The native answer is the managed pgbouncer connection pooler: DBaaS does not pool by default, but you can activate managed pgbouncer and choose transaction mode (the default, releasing the connection after each transaction) or session mode. When pooling is enabled, applications connect on port 6432 instead of the database's native 5432. Transaction-mode pooling lets a small number of real backend connections serve a large number of application clients, which is what keeps a busy stateless tier inside the RAM-derived ceiling.

Caching is the second lever and the one that substitutes for read replicas. The In-Memory DB tier (Unit 5.5) absorbs read-heavy traffic in front of the relational database with sub-millisecond retrieval, so that repeated reads never reach PostgreSQL at all. A single In-Memory DB cluster can absorb far more concurrent connections than the relational tier (the underlying Valkey engine defaults to a 10,000 client-connection ceiling), which is precisely why the cache, not the database, is the tier that faces the bursty read path. Cache-aside or write-through placement (Unit 5.5) determines consistency; either way the cache is the throughput multiplier that makes the no-read-replica platform scale.

The third lever is horizontal compute. A single node has a finite ceiling regardless of storage and pooling, so genuinely high-throughput stateless tiers scale out behind a load balancer rather than scaling a single server up indefinitely. This is also where two load-balancer realities bite. First, a Kubernetes LoadBalancer Service is a single-node static IP, not a managed distributed balancer (Unit 6.1), so it is itself a single-node ceiling unless you front the cluster with a separately provisioned Managed Application Load Balancer. Second, the managed balancers distribute but do not accelerate: the Managed Network Load Balancer and Managed Application Load Balancer both offer Round Robin, Least Connections, Random, and Source IP algorithms, and the algorithm choice governs how evenly load spreads across healthy targets, not how fast any single target runs. Least Connections smooths uneven request costs; Source IP preserves session affinity at the price of even distribution. The balancer raises aggregate throughput only by adding healthy backends, so capacity planning is ultimately backend planning.

3. Right-Sizing Versus Over-Provisioning

Right-sizing matches resources to observed demand and is the default for cost efficiency. Two platform mechanics make it less painful than it sounds. CPU, RAM, NICs, and storage can be scaled up live on Dedicated Core servers (Unit 4.3), so you can start small and grow without rebuilding; only CPU and RAM downscale and a RAM hotplug above 240 GB require a restart. And SSD storage performance grows with the volume, so growing a volume for capacity also grows its throughput, which keeps storage right-sizing and performance aligned rather than in tension.

Deliberate over-provisioning is the justified exception, and Unit 2.4 framed it as a control cost rather than waste. The clearest case is the database SSD floor from Section 1: you over-provision capacity to buy performance because the two are coupled on SSD. A second case is headroom on a tier that cannot absorb a restart gracefully during peak hours, where the cost of carrying spare CPU and RAM is cheaper than a restart-inducing downscale recovery. The discipline is to over-provision only where a measured performance floor or an operational constraint justifies it, and to right-size everywhere else.

The following table summarises where each posture applies.

4. Where Latency Is Won or Lost Across the Layered Architecture

The layered shape from Unit 1.2 (public Layer 7 balancer to stateless compute to private Layer 4 balancer to private-only data tier) is also a latency map. Each hop adds round trips, and the design goal is to keep the hot path short and the slow components off it.

The public Managed Application Load Balancer terminates TLS once at the edge and forwards to the stateless tier, so back-end hops can run plaintext on the private LAN and avoid repeated handshakes. The stateless tier should hold no session state, both because Auto Scaling and load-balancer failover require it (Units 4.3 and 7.1) and because externalising session state to the In-Memory DB tier turns a slow per-request database lookup into a sub-millisecond cache hit. The private Layer 4 balancer in front of the data tier adds a TCP pass-through hop but no TLS work. The slowest component, the relational database, sits at the bottom of the path and is shielded by both the pooler (which keeps it inside its connection ceiling) and the cache (which keeps most reads from reaching it at all). Latency is therefore won by terminating TLS once, keeping the application tier stateless and cache-fronted, and pooling every database connection; it is lost by per-request connections, under-sized SSD under the database, and reads that fall through to the relational tier instead of the cache.

One hardware nuance matters at this altitude. Very high host-network bandwidth on IONOS is a property of specific dedicated hardware, not of the general Block Storage fabric. Premium host networking appears on dedicated hardware such as the VMware Private Cloud hosts and the GPU/HPC-AI platform, while NVLink-class interconnect is specific to the Cloud GPU platform (Compute Engine GPU VMs), whose GPU servers expose two NVLink clusters of four GPUs each, addressed separately. Do not assume InfiniBand or RDMA-class performance for general Block Storage or standard compute LANs; those run the iSCSI block fabric and the standard virtual network. For FinCorp, the practical reading is that the regulated transaction tier on standard compute is engineered through correct SSD tiering, pooling, and caching, while any future low-latency HPC or AI training workload is a separate hardware conversation on the dedicated GPU platform, not an attribute the general fabric provides.

Decision Summary

Summary

Performance engineering on IONOS is a set of design-time placements rather than after-the-fact tuning: tier and size storage to its performance floor, pool and cache the database to work within fixed connection ceilings and the no-read-replica boundary, scale stateless tiers out behind balancers that distribute rather than accelerate, and keep the hot path short across the layered architecture. Over-provisioning is justified only where a measured floor or an operational constraint demands it; everywhere else, right-sizing with live growth is both cheaper and sufficient.

Key Points:

• SSD performance scales per gigabyte and degrades below ~100 GB, so database volumes are sized for performance first; HDD performance is flat and independent of volume size.
• There are no read replicas; pooling (managed pgbouncer, transaction mode, port 6432) and the In-Memory DB cache are the read-throughput levers, and the PostgreSQL connection ceiling is RAM-derived up to 1,000.
• Managed load balancers distribute traffic across healthy backends but do not speed up any single backend; a Kubernetes LoadBalancer Service is a single-node static IP.
• Right-size and live-grow by default; over-provision deliberately only at the database SSD floor or on peak tiers that cannot absorb a restart.
• Premium host networking is a property of dedicated hardware (VMware Private Cloud and GPU/HPC-AI), and NVLink-class interconnect is specific to the Cloud GPU platform (Compute Engine GPU VMs), not the general Block Storage fabric.

Important Terminology:

• Connection pooler (pgbouncer): A managed intermediary that multiplexes many application clients onto a small number of real database connections; activated explicitly, reached on port 6432, defaulting to transaction mode.
• Performance floor: The minimum volume size below which SSD storage delivers degraded throughput and IOPS (~100 GB for database workloads).
• Single-node ceiling: The finite throughput of one server or one single-node endpoint, beyond which the only remedy is scaling out across additional healthy backends.

Further Reading

• Unit 4.2: Images, Disks, and Cloud-Init (block storage tiers and the SSD floor in context)
• Unit 5.3: Relational Databases (the no-read-replica pattern and replication modes)
• Unit 5.5: In-Memory Database (the cache tier that absorbs read load)
• Unit 1.2: The Canonical Layered Architecture (the latency map this unit traces)