Hyperscaler Database vs Private Cloud Managed MariaDB

MariaDB is the default MySQL-compatible database in most Linux distributions and powers millions of web applications, SaaS platforms, and e-commerce systems. When it is time to move beyond a single self-managed instance, you face a choice: use a hyperscaler's managed MySQL service, a specialist database provider, or a private-cloud managed service.

This comparison covers six options available to Swiss organisations today.

Quick comparison

AWS RDS for MariaDB

Amazon RDS supports both MySQL and MariaDB engines. It handles provisioning, patching, backups, and Multi-AZ failover.

Strengths:

• Mature service running since 2014 for MariaDB
• Zurich region (eu-central-2) available
• Automated backups with point-in-time recovery up to 35 days
• Read replicas for scaling read-heavy workloads
• Deep integration with AWS services (Lambda, IAM, Secrets Manager)

Limitations:

• US jurisdiction. Amazon is subject to the CLOUD Act. A Zurich region does not change the legal exposure — US authorities can compel data access.
• No Swiss cloud or on-premises option. AWS RDS runs exclusively on AWS infrastructure — no deployment on cloudscale.ch, Exoscale, or your own data centre.
• AWS lock-in — VPC, IAM, and monitoring are AWS-specific. Migrating away requires re-architecting your connectivity layer.
• MariaDB version support lags behind upstream releases
• Pricing combines instance hours, storage, IOPS, and backup — monthly bills are hard to forecast

Best for: Teams already on AWS who accept US jurisdiction and want minimal setup effort.

See our MariaDB sovereignty assessment for a detailed comparison of jurisdictional risk.

Google Cloud SQL for MySQL

Cloud SQL runs MySQL (not MariaDB directly) but is MySQL wire-compatible. The Zurich region (europe-west6) keeps data in Switzerland.

Strengths:

• Zurich data centre with sub-millisecond latency from Swiss infrastructure
• Automated backups, failover, and maintenance
• Good integration with Google Kubernetes Engine and Cloud Run
• Straightforward pricing model compared to AWS

Limitations:

• Runs MySQL, not MariaDB. If your application relies on MariaDB-specific features (Galera Cluster, Aria storage engine, sequence tables, Oracle-mode syntax), Cloud SQL is not a drop-in replacement.
• Same US jurisdiction issue as AWS. Google is subject to the CLOUD Act regardless of data location.
• No Swiss cloud or on-premises option. Cloud SQL runs exclusively on Google infrastructure — no deployment on cloudscale.ch, Exoscale, or your own data centre.
• GCP lock-in — IAM, networking, and logging are GCP-specific
• Major version upgrades require downtime
• No Galera clustering for multi-primary replication

Best for: GCP-native teams using standard MySQL syntax without MariaDB-specific features.

See our MariaDB sovereignty assessment for a detailed comparison of jurisdictional risk.

PlanetScale

PlanetScale is a serverless MySQL-compatible database built on Vitess, the sharding middleware originally created at YouTube. It offers branch-based schema management and auto-scaling.

Strengths:

• Branch-based schema migrations — test schema changes before deploying to production
• Auto-scaling with no manual capacity planning
• Fast query analytics and insights dashboard
• Good developer experience for application teams

Limitations:

• Not actually MySQL or MariaDB. PlanetScale runs Vitess, which imposes restrictions: no foreign keys (by design), no stored procedures, no triggers, limited JOIN support across shards. Applications relying on these features cannot migrate without code changes.
• US company, US-hosted. No Swiss or even EU-only deployment option.
• Enterprise tier required for dedicated resources and SOC 2 compliance
• No self-hosted option — fully SaaS, no way to run on your infrastructure
• Pricing based on rows read/written — costs are unpredictable for write-heavy workloads

Best for: Startups building new applications that can work within Vitess constraints and do not need data residency.

Aiven for MySQL

Aiven deploys managed MySQL on AWS, GCP, or Azure in your chosen region. Like the PostgreSQL offering, it provides a multi-cloud abstraction layer.

Strengths:

• EU-headquartered company (Helsinki, Finland)
• Multi-cloud deployment — same provider on AWS, GCP, or Azure
• Terraform provider for infrastructure-as-code management
• Includes connection pooling and query statistics

Limitations:

• Runs MySQL, not MariaDB. Aiven's MySQL service uses Oracle MySQL, not MariaDB. MariaDB-specific features are not available.
• Deployed on US hyperscaler infrastructure even in EU regions — CLOUD Act exposure via the underlying provider
• No dedicated Swiss region on Swiss-owned infrastructure
• No Galera clustering option
• Premium pricing tier required for 99.99% SLA

Best for: Multi-cloud teams wanting MySQL as a service with a single management interface.

Self-Hosted MariaDB

Running MariaDB on your own servers or cloud VMs gives you complete control. You choose the version, the configuration, and where data lives.

Strengths:

• Full control over data location, configuration, and access
• Native MariaDB with all features — Galera Cluster, Aria engine, Oracle-mode syntax
• No per-service fees beyond infrastructure costs
• Can run on Swiss cloud providers (cloudscale.ch, Exoscale)

Limitations:

• Operational overhead is real. Production MariaDB requires:
• Backup automation and regular restore testing
• Galera Cluster setup and split-brain prevention
• Security patching including zero-day response
• Monitoring for replication lag, connection limits, and disk usage
• Major version upgrades with application compatibility testing
• Performance tuning (query cache, InnoDB buffer pool, thread pool)
• A database administrator in Switzerland costs CHF 120,000-150,000/year
• Galera Cluster is powerful but operationally complex — node recovery, SST/IST transfers, and quorum management require expertise
• Teams without dedicated DBA capacity often run outdated versions with untested backups

Best for: Organisations with a dedicated database team that needs full customisation.

VSHN Managed MariaDB

VSHN operates your MariaDB instance on the infrastructure you choose. You get native MariaDB with Galera Cluster for high availability, managed by a Swiss team under Swiss jurisdiction.

Strengths:

• Swiss company, Swiss jurisdiction — VSHN is headquartered in Zurich. No CLOUD Act exposure through the operations layer.
• Native MariaDB, not MySQL. Full compatibility with MariaDB-specific features — Galera Cluster, Aria engine, sequence tables, Oracle-mode syntax.
• Your infrastructure, your choice — cloudscale.ch, Exoscale, or on-premises
• Galera Cluster with 3-node replication for high availability and automatic failover
• Automated backups via K8up with configurable schedule and retention
• Up to 99.99% SLA with service credits
• ISO 27001 certified operations since 2014
• Self-service provisioning via Kubernetes API or Servala

Pricing:

Computing resources (CPU, memory, storage) are billed separately by the infrastructure provider. Support is available via VSHN support plans.

Best for: Swiss companies needing a MySQL-compatible managed database with data sovereignty, predictable costs, and no vendor lock-in.

MySQL compatibility matters

One detail often overlooked in database comparisons: not all "MySQL-compatible" services run actual MySQL or MariaDB.

If your application uses foreign keys, stored procedures, or MariaDB-specific features, only AWS RDS (with MariaDB engine), self-hosted, and VSHN Managed are drop-in options.

The sovereignty question

For Swiss companies subject to data protection regulations, the legal jurisdiction of the service operator matters as much as the physical data location.

Choosing VSHN with cloudscale.ch or Exoscale eliminates US jurisdiction exposure entirely — both the operations company and the infrastructure provider are Swiss.

For a detailed sovereignty analysis, see our MariaDB sovereignty assessment.

When to choose VSHN

VSHN Managed MariaDB fits when:

• Your application needs native MariaDB features (Galera Cluster, Aria, Oracle-mode syntax) that MySQL-only services do not support
• Data must stay under Swiss jurisdiction — not just in a Swiss data centre operated by a US company
• You want high availability with Galera clustering without managing node recovery and quorum yourself
• Your development team should focus on application features, not database operations
• You need predictable monthly costs instead of per-IOPS or per-row pricing that fluctuates

Next steps

Ready to discuss your MariaDB setup? Book a free 15-minute call with our team. We will review your current workload and recommend the right approach — whether that is VSHN, a hyperscaler, or self-hosted.