Which managed MySQL platform is best for a small Node.js SaaS?

Aiven offers a low-cost conventional MySQL entry point with its Developer and Startup tiers. If your app already runs on Azure, Google Cloud, or AWS, the native database service often simplifies networking and identity. PlanetScale is most relevant when Vitess-based horizontal scaling and database branching are genuine requirements from day one.

Is Aurora Serverless v2 cheaper than a provisioned MySQL instance?

It can be for variable workloads, but not automatically. Aurora Serverless v2 has a non-zero minimum ACU capacity plus separate charges for storage, I/O, backups, replicas, and cross-AZ networking. Model a full month at minimum, average, and peak ACUs before committing. Sustained high throughput may favor provisioned instances with reserved pricing.

How many MySQL connections should a Node.js application open?

Use a bounded connection pool per long-running process and keep the combined maximum below the database connection limit with headroom for jobs, migrations, admin tools, and failover. For serverless functions, keep pool sizes conservative or use a managed proxy to prevent connection storms from concurrent cold starts.

Do I need read replicas for my SaaS application?

Read replicas help offload reporting, dashboards, and eventually-consistent read traffic from the primary instance. They do not increase write throughput. If your write load exceeds a single primary, consider PlanetScale Vitess for horizontal sharding or evaluate whether your data model can be partitioned across multiple databases.

Best Managed MySQL Hosting Platforms for Node.js SaaS Apps in 2026

Introduction

Choosing a managed MySQL platform is not simply a search for the lowest monthly price. High availability, read replicas, IOPS, backups, private networking, monitoring, and connection management can cost more than the base instance itself. This guide compares five platforms across different architectural models—sharded Vitess, autoscaling Aurora, hyperscaler-managed MySQL, and multi-cloud managed open source—so Node.js SaaS teams can make a production-grade decision backed by real cost estimates.

The platforms covered: PlanetScale Vitess, Amazon Aurora MySQL Serverless v2, Google Cloud SQL for MySQL, Azure Database for MySQL Flexible Server, and Aiven for MySQL. Pricing reflects official pages queried on 2026-07-12. Always confirm current pricing, regional availability, and plan limits before purchasing.

Quick Verdict

Platform	Best Fit	Pricing Shape	Main Strength	Main Trade-off
PlanetScale Vitess	SaaS products expecting horizontal sharding and high connection counts	Resource-based cluster, VTGate, storage, egress, and add-ons	MySQL-compatible Vitess architecture with database workflow tooling	Not identical to a conventional standalone MySQL server
Amazon Aurora MySQL Serverless v2	AWS-native workloads with variable demand	ACU-hours plus storage, I/O, backups, and data transfer	Autoscaling with deep AWS service integration	Multiple billing dimensions and a non-zero minimum capacity
Google Cloud SQL for MySQL	Teams already on Google Cloud	vCPU, memory, storage, networking, HA, and edition pricing	Familiar MySQL with committed-use discounts	Replicas and HA significantly increase effective cost
Azure Database for MySQL Flexible Server	Azure-native SaaS with private networking	Burstable, General Purpose, or Memory Optimized compute plus storage and IOPS	Flexible sizing, stop/start, and Azure ecosystem integration	Cost varies widely by region, tier, IOPS, backup, and reservation
Aiven for MySQL	Multi-cloud teams wanting packaged managed operations	Free and fixed starting tiers, then larger plans	Multi-cloud portability and a low-cost developer tier	Production HA pricing jumps considerably from entry plans

For a small conventional workload, Aiven provides a simple entry point. For AWS, Google Cloud, or Azure-centered architectures, the native database service usually reduces networking and identity complexity. PlanetScale is differentiated when Vitess and horizontal scaling are real requirements, not aspirational ones.

What Matters When Comparing Managed MySQL

High Availability and Recovery

High availability keeps the service running through an instance or zone failure. Backups and point-in-time recovery (PITR) protect against accidental deletion, faulty deployments, and corrupted data. Every production system needs both.

Verify failover behavior under load, standby instance billing, backup retention windows, cross-region recovery options, and measured restore speed before committing to a platform.

Connection Limits and Pooling

Node.js applications typically use connection pools. If ten application instances each open 50 connections, the database receives 500 connections before accounting for background jobs, migrations, administration tools, and failover headroom.

// Safe pool configuration with mysql2
import mysql from 'mysql2/promise';

const pool = mysql.createPool({
  host: process.env.DB_HOST,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  database: process.env.DB_NAME,
  waitForConnections: true,
  connectionLimit: 20,        // Conservative per-instance limit
  queueLimit: 0,              // Unlimited queue (fail fast in practice)
  enableKeepAlive: true,
  keepAliveInitialDelay: 10000,
});

Serverless functions can create connection storms when concurrent invocations each open a new pool. Use a managed database proxy (RDS Proxy, Cloud SQL Auth Proxy) or enforce strict per-function pool limits.

Read Scale vs. Write Scale

Read replicas serve reports and eventually-consistent workloads, but they do not increase the write capacity of a single primary. PlanetScale’s Vitess architecture targets horizontal sharding for write scale. The hyperscaler services are simpler when one primary can handle your write throughput.

ORM Compatibility

Prisma, Drizzle, Sequelize, TypeORM, Knex, and mysql2 all work with managed MySQL, but teams should test:

Migrations against the target engine version
Transaction isolation levels and prepared statement handling
Failover reconnection behavior and connection error surfacing
Read/write routing when replicas are in use
Time zone handling and engine-specific SQL features

// Prisma datasource with connection pooling and replica awareness
datasource db {
  provider = "mysql"
  url      = env("DATABASE_URL")
}

// Use read replicas via middleware or a separate client
const replicaUrl = process.env.DATABASE_REPLICA_URL;

Platform Comparison

PlanetScale Vitess

PlanetScale provides a Vitess-based MySQL-compatible platform. Vitess adds routing, sharding, and a control layer around MySQL instances, making it architecturally distinct from a standalone MySQL server.

Pricing factors (confirm before publishing): instance size, VTGate configuration, storage beyond the first 10 GB, production branches requiring at least three instances for HA, and egress beyond the included 100 GB.

PlanetScale fits teams that genuinely need horizontal sharding, high connection scale, and database deployment workflows with branching. The trade-off is architectural: validate transactions, migrations, query patterns, and connection behavior rather than assuming every conventional MySQL pattern works unchanged.

Amazon Aurora MySQL Serverless v2

Aurora integrates deeply with VPC, IAM, CloudWatch, RDS Proxy, AWS Backup, Lambda, ECS, and EKS. Serverless v2 scales in Aurora Capacity Units (ACUs).

Illustrated pricing (US East, confirm before publishing): Aurora Standard at $0.12/ACU-hour, Aurora I/O-Optimized at $0.156/ACU-hour, with a 0.5 ACU minimum. Storage, I/O under Standard, backups, replicas, and cross-AZ transfer add to total cost.

Aurora fits AWS-native applications with variable load and private networking requirements. The main risk is assuming autoscaling guarantees low cost—sustained capacity and heavy I/O may make a provisioned comparison necessary.

// Connecting to Aurora via RDS Proxy with IAM authentication
import { Signer } from '@aws-sdk/rds-signer';

const signer = new Signer({
  hostname: process.env.RDS_PROXY_ENDPOINT,
  port: 3306,
  username: 'iam_user',
});

const token = await signer.getAuthToken();
const connection = await mysql.createConnection({
  host: process.env.RDS_PROXY_ENDPOINT,
  user: 'iam_user',
  password: token,
  ssl: { rejectUnauthorized: true },
});

Google Cloud SQL for MySQL

Cloud SQL provides conventional managed MySQL with maintenance, backups, replicas, HA, private networking, and deep Google Cloud integration. Google currently separates Enterprise and Enterprise Plus editions.

Illustrated pricing (confirm before publishing): Enterprise starting at $0.0413/vCPU-hour and $0.007/GB memory-hour, SSD storage at $0.17/GB-month. Enterprise Plus starts higher and offers a stronger availability SLA. Region and edition change pricing meaningfully.

Cloud SQL is a natural fit for Cloud Run, GKE, or Compute Engine workloads. One-year and three-year committed-use discounts help stable production workloads, but HA, replicas, and connection management must be included in the estimate.

Azure Database for MySQL Flexible Server

Azure Flexible Server runs MySQL Community Edition and supports Burstable, General Purpose, and Memory Optimized compute tiers. It provides VNet integration, firewall-controlled public access, replicas, automated backups, configurable IOPS, and stop/start capability.

Key cost lever: Microsoft states that compute billing stops while a server is stopped, reducing development and staging costs. Exact pricing depends on region, tier, storage, IOPS, backup retention, HA configuration, and reservations.

Azure fits App Service, AKS, Functions, and VM workloads needing private VNet access. Burstable compute may suit development or light workloads, but production sizing must include I/O and failover behavior.

Aiven for MySQL

Aiven offers managed MySQL across multiple clouds and regions with backups, PITR, replicas, encryption, VPC peering, and monitoring integrations.

Current public tiers (confirm before publishing): Free (learning/evaluation), Developer at $5/month, Startup starting at $75/month, Business starting at $180/month. Aiven advertises predictable billing and a 99.99% uptime SLA, but verify the plan and topology that deliver it.

Aiven fits teams valuing multi-cloud choice, packaged operations, managed upgrades, and predictable tiered pricing. The main trade-off is the price jump from development to production HA.

The Real Managed MySQL Cost Stack

The instance is only the first component. Model these eight layers for a realistic twelve-month projection:

Cost Layer	What to Include
Compute	vCPU, memory, ACUs, burst credits, or cluster nodes
High Availability	Standby instances and regional failover capacity
Storage	Primary data, replicas, temporary space, and growth headroom
I/O and IOPS	Reads, writes, provisioned IOPS, or I/O-optimized pricing
Networking	Egress, private endpoints, cross-zone, and cross-region traffic
Backups	Snapshots, PITR logs, long retention, and exports
Observability	Query insights, logs, metrics, and third-party monitoring
Operations	Migration, support, incident response, and engineering time

Compare normal traffic, peak traffic, failover load, and twelve months of projected growth. A $50/month instance can easily become $300/month once HA, backups, IOPS, and egress are included.

Node.js Connection and Deployment Guidance

Use a Bounded Pool

Create one shared pool per long-running Node.js process. Define maximum size, acquisition timeout, idle timeout, and a queue for requests waiting on a connection.

Total connection budget = (app instances × pool max) + jobs + migrations + admin tools + failover headroom

Treat Serverless Differently

Reuse connections across warm invocations where the runtime supports it. Keep pool sizes conservative (single digits per function instance). Consider a managed database proxy (RDS Proxy, Cloud SQL Auth Proxy) to multiplex connections. Never create a new pool for every HTTP request.

Separate Analytics from Transactions

Large exports and dashboard scans should not compete with customer-facing transactions. Route analytical queries to read replicas, a data warehouse, or a separate analytical store when reporting volume grows.

Test Failover Under Load

Managed failover still causes connection errors and retries. Log pool errors, transaction failures, host changes, and query latency. Run a controlled failover and restore test before launch.

// Logging pool errors for failover visibility
pool.on('error', (err) => {
  console.error('Unexpected pool error', {
    code: err.code,
    fatal: err.fatal,
    message: err.message,
  });
});

pool.on('acquire', (connection) => {
  // Track connection acquisition for pool sizing
});

pool.on('release', (connection) => {
  // Track release for leak detection
});

Decision Framework

Choose PlanetScale Vitess for real horizontal-sharding and connection-scale requirements where Vitess architectural differences are acceptable.
Choose Aurora Serverless v2 for variable AWS-native workloads with existing VPC, IAM, and CloudWatch investment.
Choose Google Cloud SQL for conventional MySQL in GCP with committed-use pricing benefits.
Choose Azure Flexible Server for Azure networking, operations tooling, and Microsoft cloud procurement.
Choose Aiven for multi-cloud portability and packaged managed open-source operations.

Validate your shortlist with production-like data, realistic connection counts, failover and restore tests, ORM migration runs, and a twelve-month total cost model before committing.

Production Readiness Checklist

Choose a supported MySQL version with a known end-of-support date
Enable TLS and private networking for all database traffic
Store credentials in a secrets manager (AWS Secrets Manager, Google Secret Manager, Azure Key Vault, HashiCorp Vault)
Configure automated backups and point-in-time recovery
Test a full restore from backup before launch
Enable high availability for critical production workloads
Set bounded connection pools with acquisition and idle timeouts
Monitor connections, slow queries, storage utilization, and IOPS
Test failover under realistic load and measure recovery time
Verify ORM migrations and transactions against the target engine
Separate reporting and analytical traffic from transactional traffic
Document replica consistency guarantees and maintenance windows
Estimate cross-AZ and cross-region network charges
Document an exit and migration plan before you need it

Recommendations by Company Stage

Early-Stage SaaS

Use a small conventional managed MySQL instance unless Vitess or autoscaling solves a known, measured problem. Aiven Developer or a small cloud-native instance may suffice, but do not depend on a free tier without tested backups and availability. Invest in connection pooling discipline early.

Growing SaaS

Prioritize high availability, private networking, point-in-time recovery, query monitoring, and predictable connection behavior. Compare providers using real database size, query patterns, and traffic profiles. Run a cost model that includes HA, backups, IOPS, and egress—not just the base instance price.

Enterprise or High-Scale Platform

Evaluate multi-region recovery, contractual SLA, audit logs, encryption controls, dedicated support, replication lag, write scaling strategy, connection proxies, and migration assistance. PlanetScale becomes more relevant when horizontal sharding is required. Hyperscaler services remain attractive when the database must align tightly with one cloud’s identity, networking, and compliance framework.

Conclusion

There is no universal best managed MySQL platform. PlanetScale provides the most differentiated architecture for Vitess and horizontal scaling. Aurora Serverless v2 is compelling for variable AWS-native workloads. Cloud SQL and Azure Flexible Server provide familiar managed MySQL inside their cloud ecosystems. Aiven offers a portable managed-service experience with a low-cost entry tier.

Choose by write scale, connection behavior, cloud boundary, availability target, recovery requirements, and total cost—not by sticker price alone. Treat failover, restore, migration, and connection-pool tests as purchasing criteria rather than post-launch tasks. A database decision made with real data and tested assumptions pays for itself many times over in production.