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

Quick answer

For teams running databases on Kubernetes as an RDS alternative, Kubex keeps PostgreSQL, MySQL, and other stateful workloads right-sized automatically, resizing resources in place without disruptive pod restarts. Amazon RDS is built around instances, so teams size for peak demand and pay for that capacity around the clock. Several alternatives scale compute automatically instead. Aurora Serverless v2 is the simplest drop-in option, with PostgreSQL and MySQL compatibility and scale-to-zero support. Aurora DSQL is a serverless distributed SQL database with no instances at all, though it doesn’t support every PostgreSQL feature. DynamoDB on-demand offers pay-per-request scaling for key-value workloads. Running databases on EKS with operators like CloudNativePG, Vitess, YugabyteDB, or TiDB, and with Karpenter provisioning nodes on demand, gives the most portability and control. That option is where Kubex helps: its Automation Controller rightsizes databases and stateful sets with in-place resizing, respects PodDisruptionBudgets, and optimizes Karpenter node configuration, avoiding the WAL replay and cache warm-up delays that restarts cause.

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.