SaaS products run on infrastructure. That sounds obvious, but the choices you make determine whether your application still runs smoothly at ten thousand users, or whether you're firefighting every Friday afternoon. This article covers the fundamentals: what infrastructure layers a SaaS platform needs, what the trade-offs are, and how to organise this in the Netherlands.
What makes SaaS hosting different
A static website you host on a VPS and you're done. SaaS works differently. Your application serves multiple customers simultaneously, processes data that belongs to them (not you), and must be available while you sleep. That puts different demands on the layer beneath it.
The three things that always come up with SaaS infrastructure:
- Multi-tenancy – multiple customers on the same codebase, with strict data isolation
- Elasticity – resources that scale with usage, not with a monthly estimate
- Compliance – GDPR, NIS2 and sector-specific requirements demand demonstrable security
SaaS companies running on hyperscalers (AWS, Azure, GCP) spend on average 18 to 30% of their revenue on cloud costs as they scale. For early teams that's acceptable. For established products it starts to chafe. That's when fixed infrastructure in a Dutch datacenter becomes interesting.
The SaaS infrastructure stack
Each layer needs its own management, monitoring and redundancy
Compute: dedicated vs. shared
The first choice is compute: do you buy capacity from a hyperscaler, rent dedicated servers, or build a private cloud? For SaaS there are three common models:
Public cloud (hyperscaler): maximum flexibility, but higher cost per vCPU with stable usage. Data sovereignty can be an issue with US companies due to the Cloud Act.
Dedicated hosting in NL: fixed costs, full control over hardware. Ideal for workloads with predictable consumption. Brings more operational responsibility.
Private cloud: the sweet spot for larger SaaS players. VMware, OpenStack or Proxmox on your own hardware in a Dutch datacenter. Full control, scalable, and data never leaves the Netherlands.
Many SaaS companies choose a hybrid approach: base load on dedicated or private cloud, catching peaks via burst capacity with a local cloud provider.
Networking: latency matters
Dutch SaaS customers expect response times under 50 milliseconds. That's achievable if you're within AMS-IX reach. Amsterdam is Europe's largest internet exchange, with more than 1,000 connected networks. Hosting in a Dutch facility that peers directly with AMS-IX gives structurally lower latency than a region in Frankfurt or Dublin.
Besides latency, bandwidth plays a role. SaaS applications with heavy file or video traffic need 10G uplinks. Make sure your provider delivers this without oversubscription, or know what the oversubscription ratio is.
Storage: block, object or file?
SaaS applications typically use three types of storage:
- Block storage – for databases (PostgreSQL, MySQL). Low latency, high IOPS. NVMe is the standard for new installations.
- Object storage – for user files, uploads, media. S3-compatible API is the de facto standard. Multiple providers offer this in the Netherlands.
- File storage (NFS/NAS) – for shared volumes in clustered environments. Less common in modern SaaS but still relevant with legacy systems.
Make sure backup and replication are configured before your first customer goes live. RPO (how much data loss you accept) and RTO (how fast you recover) are choices you need to make deliberately, not things you'll sort out "later".
Security and compliance built in
GDPR requires SaaS providers to process personal data of EU citizens responsibly. NIS2, effective in the Netherlands via the Cybersecurity Act, sets additional requirements for the security of digital service providers. ISO 27001 is the most commonly used standard to demonstrate this.
Infrastructure choices directly affect your compliance position. Hosting in the Netherlands with an ISO 27001-certified provider is much easier to justify to customers than datacenters outside the EU.
Infrastructure choice per phase
- Low startup costs
- No hardware management
- Pay-as-you-go
- Fixed base load NL
- Burst to cloud
- Cost optimisation
- Full control
- Data in NL
- Lower TCO at scale
- Geo-redundancy
- SLA-guaranteed
- Dedicated support
Monitoring and observability
Infrastructure without monitoring is driving blind. A minimal SaaS stack needs:
- Infrastructure metrics: CPU, memory, disk I/O, network (Prometheus/Grafana)
- Application performance: response times, error rates, tracing (OpenTelemetry)
- Log aggregation: centralised, searchable, retained according to GDPR retention periods
- Uptime monitoring: external, because internal monitoring won't catch a complete outage
Set up alerting based on SLOs (Service Level Objectives), not on thresholds for individual metrics. "CPU is 80%" is less relevant than "API error rate is above 1%".
How to get started
The most common mistake is locking in too many infrastructure choices too early. Start with a simple setup you understand and can manage, and build from there. Kubernetes on day one is rarely needed. A solid foundation with managed databases, object storage and a good CI/CD pipeline will take you further than most SaaS companies get in their first year.
Once you know what your traffic looks like, what your peaks are and where your bottlenecks sit, you can invest targeted in the next layer. Infrastructure is a growth factor, not a one-time decision.
Looking for SaaS hosting? See our SaaS solutions.