How to choose an RDS alternative that scales without provisioning instances?

Amazon RDS is reliable and familiar, but it’s built around instances. You pick an instance class, size it for peak demand, and pay for that capacity around the clock, even overnight when traffic drops to a trickle. Scaling up usually means a failover or maintenance window. For workloads with spiky, unpredictable, or intermittent demand, that model leads to either overprovisioning or performance risk.

The good news is that several options now scale compute automatically. The right choice depends on your compatibility needs, traffic patterns, and how much operational control you want.

Aurora Serverless v2

For most RDS users, Aurora Serverless v2 is the easiest step. It’s PostgreSQL and MySQL compatible, and capacity adjusts automatically within a range you set. Capacity is measured in Aurora Capacity Units (ACUs), each roughly 2 GiB of memory with corresponding CPU and networking.

Since late 2024, it can also scale to zero. Setting the minimum capacity to 0 ACUs lets instances pause automatically when there are no user connections, and you aren’t charged for instance capacity while paused. The trade-off is a cold start of roughly 15 seconds on resume, so a small non-zero minimum is still wise for latency-sensitive production workloads. Watch I/O costs too, since for high-throughput OLTP workloads, I/O charges can exceed ACU charges.

Aurora DSQL

Aurora DSQL is a newer option with no instances or capacity ranges at all. It’s a serverless, distributed SQL database where reads and writes scale automatically and independently without sharding or instance upgrades. It’s designed for 99.99% single-Region and 99.999% multi-Region availability.

The catch is compatibility. DSQL is PostgreSQL-compatible but doesn’t support every PostgreSQL feature, and it isn’t available with MySQL compatibility. Test your schema and queries before committing.

DynamoDB

If your data model can shift away from relational, DynamoDB in on-demand mode offers true pay-per-request scaling. It’s a strong fit for key-value access patterns but typically requires significant application redesign.

Running databases on Kubernetes

If you already run EKS, hosting databases in Kubernetes is another path. You still use nodes, but autoscalers like Karpenter provision them on demand, so you never manage instances directly. Popular open-source operators include CloudNativePG for PostgreSQL and Vitess for horizontally scaling MySQL. Distributed SQL databases like YugabyteDB and TiDB also run natively on Kubernetes.

This option offers portability and control but adds operational responsibility for backups, upgrades, and failover.

Key selection criteria

Compatibility: Confirm engine and feature support before migrating, especially for DSQL.
Traffic pattern: Intermittent workloads benefit most from scale-to-zero, while steady workloads may be cheaper on provisioned capacity with commitments.
Cost model: Compare ACU, request-based, and I/O pricing against real usage, not list prices.
Latency tolerance: Cold starts matter for user-facing services.
Operational appetite: Managed serverless minimizes toil, while Kubernetes-hosted databases maximize control.

Where Kubex fits

If you run databases on Kubernetes, rightsizing them is critical and traditionally painful. Restarting a PostgreSQL pod to resize it triggers WAL replay from the last checkpoint, and restarting caches or brokers causes warm-up and rebalancing delays.

Kubex matches databases and stateful sets to durable, right-sized resources. The Kubex Automation Controller supports in-place container resizing without pod restarts (Kubernetes 1.33+), with automatic fallback to pod eviction, and it respects PodDisruptionBudgets, making it well suited to stateful workloads. Kubex also optimizes Karpenter node configuration, so the nodes under your databases scale efficiently too.

Useful links:

• Kubex Automation Controller overview: https://docs.kubex.ai/docs-kubex/Content/Kubex/Automation_Overview
• Kubex Helm charts: https://github.com/densify-dev/helm-charts/tree/master/charts

For drop-in RDS compatibility, Aurora Serverless v2 is the simplest choice. For global scale with no capacity planning, Aurora DSQL is compelling if your workload fits. For maximum control on EKS, Kubernetes-hosted databases paired with Kubex keep stateful workloads right-sized without disruptive restarts.