AWS RDS vs Aurora vs PlanetScale — Database for Kubernetes Apps 2026

Databases are the hardest part of Kubernetes architecture. Run it inside the cluster (StatefulSet), use a managed service, or go cloud-native serverless? The right answer depends on your scale and requirements.

The Three Options

AWS RDS — Managed traditional databases (PostgreSQL, MySQL, MariaDB, Oracle, SQL Server). You choose instance type, pay hourly.

Amazon Aurora — AWS's cloud-native relational database. Compatible with PostgreSQL and MySQL but fundamentally redesigned for cloud. More expensive, much better performance.

PlanetScale — Serverless MySQL-compatible database built on Vitess. Pay per query, not per instance. Horizontal sharding built-in.

AWS RDS

What it is

Managed PostgreSQL/MySQL on dedicated EC2 instances. AWS handles backups, patching, failover.

Pricing

db.t3.micro  (2 vCPU, 1GB)  — $0.018/hr = $13/month
db.t3.medium (2 vCPU, 4GB)  — $0.068/hr = $49/month
db.r6g.large (2 vCPU, 16GB) — $0.214/hr = $154/month
+ Storage: $0.115/GB/month (gp2)

Connecting from Kubernetes

# Store RDS credentials as K8s secret
apiVersion: v1
kind: Secret
metadata:
  name: rds-credentials
stringData:
  host: mydb.xxxxx.us-east-1.rds.amazonaws.com
  port: "5432"
  database: myapp
  username: admin
  password: supersecretpassword
 
# Use in deployment
env:
  - name: DATABASE_URL
    value: "postgresql://$(DB_USER):$(DB_PASS)@$(DB_HOST):$(DB_PORT)/$(DB_NAME)"

Better approach: Use AWS Secrets Manager + External Secrets Operator to inject RDS credentials without storing them in Kubernetes secrets.

Multi-AZ

# Terraform: RDS Multi-AZ
resource "aws_db_instance" "production" {
  instance_class        = "db.t3.medium"
  engine                = "postgres"
  engine_version        = "15.4"
  multi_az              = true   # Standby in different AZ, auto-failover
  backup_retention_period = 7
  deletion_protection   = true
  
  performance_insights_enabled = true  # Query performance monitoring
}

Best for

• Traditional applications that need standard PostgreSQL/MySQL
• Teams familiar with relational databases
• Cost-sensitive workloads that don't need Aurora-level performance

Amazon Aurora

What's different

Aurora rewrites the storage layer. Instead of one server writing to one EBS volume, Aurora writes to 6 storage nodes across 3 AZs simultaneously. Durability is built into the storage, not the compute.

Result: 5x PostgreSQL performance, 3x MySQL performance for write-heavy workloads.

Aurora Serverless v2

The most interesting Aurora feature for Kubernetes teams:

resource "aws_rds_cluster" "production" {
  engine         = "aurora-postgresql"
  engine_version = "15.4"
  
  serverlessv2_scaling_configuration {
    min_capacity = 0.5   # 0.5 ACU minimum (can pause to 0)
    max_capacity = 16    # Scale up to 16 ACUs automatically
  }
}

Aurora Serverless v2 scales ACUs (Aurora Capacity Units) in seconds based on load. No more guessing instance sizes. Idle capacity can scale to near-zero.

Pricing: $0.12 per ACU-hour. 1 ACU ≈ 2GB RAM + proportional CPU.

Aurora vs RDS: When to Use Aurora

Aurora for Kubernetes

Aurora Serverless v2 is ideal for Kubernetes workloads:

• HPA scales your app pods up → Aurora scales up automatically
• Traffic drops → Aurora scales down → cost drops

# Python connection pool for Aurora Serverless v2
# Use smaller pool size — serverless can spin up fast
import psycopg2.pool
 
pool = psycopg2.pool.ThreadedConnectionPool(
    minconn=1,    # Don't hold too many connections
    maxconn=10,
    host=os.getenv("AURORA_HOST"),
    database="myapp",
    user="admin",
    password=os.getenv("DB_PASSWORD")
)

PlanetScale

What it is

Serverless MySQL-compatible database built on Vitess (the database powering YouTube, Slack, GitHub). Designed for horizontal scalability from the start.

Unique Features

Non-blocking schema migrations — Change schema without locking tables:

-- PlanetScale deploy request
-- No downtime, no table locks, works on tables with billions of rows
ALTER TABLE users ADD COLUMN last_login_at DATETIME;

Branching — Database branches like Git branches:

pscale branch create my-database feature-new-schema
pscale deploy-request create my-database feature-new-schema
# Review diff, approve, merge — exactly like a PR

Connection pooling built-in — PlanetScale handles connection pooling at the platform level. Your Kubernetes pods each connect directly without PgBouncer/ProxySQL.

Pricing

Free tier: 5GB storage, 1 billion row reads/month, 10M row writes/month — genuinely useful.

Scaler Pro: $39/month for production (starts at 1/8th server, auto-scales).

Hobby: Free forever for personal projects.

Connecting from Kubernetes

import os
import pymysql
 
conn = pymysql.connect(
    host=os.getenv("PLANETSCALE_HOST"),      # aws.connect.psdb.cloud
    user=os.getenv("PLANETSCALE_USERNAME"),
    password=os.getenv("PLANETSCALE_PASSWORD"),
    database=os.getenv("PLANETSCALE_DATABASE"),
    ssl_ca="/etc/ssl/certs/ca-certificates.crt",
    ssl_verify_cert=True,
)

Best for

• Applications with unpredictable or bursty traffic
• Teams that want zero ops for database management
• Multi-region reads (PlanetScale has global replicas)
• MySQL-compatible apps that want Git-like schema workflows

Limitations

• MySQL only (no PostgreSQL)
• No stored procedures, foreign keys (Vitess limitation)
• US-east focused (latency from India to PlanetScale can be 150ms+)

Decision Guide

For most Kubernetes apps starting out: RDS PostgreSQL on t3.medium — simple, reliable, $49/month. Graduate to Aurora Serverless v2 when traffic is unpredictable.

Learn AWS database services with hands-on practice at KodeKloud — their AWS courses cover RDS, Aurora, and database architecture patterns.