PostgreSQL and MariaDB autoscaling: how full-stack autoscaling closes the database gap

When platform providers talk about autoscaling, they usually mean one thing: application autoscaling, adding or removing web instances based on traffic. The pattern is well understood. Define a metric, set a threshold, and let the platform act on it.

Most platforms still leave database capacity as a separate, mostly manual problem. Teams either pre-provision for the worst hour of the worst day, upgrade plans on a calendar, or wire together their own scaling logic on Kubernetes or RDS. The result is the same in each case: capacity that doesn't match demand, and operational overhead that doesn't earn its keep.

What "full-stack autoscaling" actually scales

The phrase gets used loosely. Here's how we use it on Upsun:

Full-stack autoscaling: every layer of your stack scales itself with demand, natively, on one platform: applications, workers, and managed databases.

Concretely, three things scale horizontally on the same Upsun primitive:

• Applications: your web tier.
• Workers: background and async processes such as payments, video transcoding, AI inference, and scheduled batch jobs.
• Managed databases: read-only replicas of PostgreSQL and MariaDB

All three respond to the same signals: average CPU and memory utilization across running instances. All three follow the same logic: add capacity when utilization stays above a threshold, remove it when utilization stays below one. All three live in the same project, on the same bill, with one mental model.

How read replica autoscaling works

Autoscaling on Upsun is horizontal: it adds or removes whole instances of a service. For databases, that means scaling the read replica pool of your primary PostgreSQL or MariaDB service. You configure a baseline replica once; autoscaling adjusts the pool size from there in response to load.

The platform watches the average CPU and memory utilization of your running replica pool. When utilization stays above your scale-up threshold for the evaluation period, an additional replica joins the cluster. When it stays below your scale-down threshold for the evaluation period, an additional replica is removed. A cooldown window between actions prevents the pool from oscillating up and down on short bursts.

Defaults give you a sense of the shape:

• Scale-up threshold: 80% CPU for 5 minutes
• Scale-down threshold: 20% CPU for 5 minutes
• Cooldown window: 5 minutes between scaling actions
• Instance limits: 1 to 8 per environment, region-dependent

You can use CPU, memory, or both as triggers, and you can tune every threshold per environment, including development and staging, not just production.

Two technical details matter for honest expectations:

1. Replication is asynchronous. Writes hit the primary first, then stream to the replicas. Delays are typically a few milliseconds, but if your application needs read-after-write consistency on critical data and can't tolerate that gap, route those queries to the primary.
2. Replicas are strictly read-only. Write attempts on a replica return a SQL error. This is enforced at the engine level, not in application logic.

Your application code is responsible for directing read queries to the replica. The connection string is exposed through PLATFORM_RELATIONSHIPS under the replica relationship name (for example, database-readonly). Most ORMs and database libraries support this pattern with a separate read connection. It's a code change, not an infrastructure one.

Why "native" is the word that matters

There are three other ways to get database autoscaling today. Each is real, and each comes with trade-offs Upsun is explicitly trying to avoid.

1. Third-party serverless databases: Some platforms route customers to a separate database engine. Netlify, for example, ships its database product on Neon. That works, but it puts your data on a different vendor, a different SLA, a different bill, and often a different region pairing than your application.
2. DIY on Kubernetes: You can run a PostgreSQL operator with HPA, configure custom metrics adapters, and get autoscaling that way. You'll also own the operator upgrades, the HA topology, the failover testing, and the on-call rotation for all of it. 
3. Manual scaling on cloud providers: On AWS, you can wire up HPA for your app, set RDS read replicas with scheduled or alarm-driven scaling, configure CloudWatch metrics, and operate the assembly.  Same functional outcome, significantly more operational overhead, and you own every piece of the integration.

Upsun's read replica autoscaling runs directly on the managed PostgreSQL and MariaDB services that already power your project. No third engine, additional layer, or assembly required.

When read replica autoscaling is the right fit

This feature is purposely scoped. It's designed for workloads where adding read capacity actually relieves database pressure.

It's a strong fit for:

• Read-heavy production applications, including listing pages, dashboards, search-driven UIs
• Reporting and analytics jobs that pull from production data
• Background jobs that frequently query but rarely write
• Campaign or event-driven traffic such as  flash sales, ticket launches, admissions periods, and content drops
• Applications running on managed PostgreSQL or MariaDB on Upsun Flex

It's not the right fit for:

• Write-heavy workloads: If your bottleneck is write throughput on the primary database, adding read replicas won't help. Write scaling is a different problem entirely, usually solved with sharding, partitioning, or a fundamentally different storage architecture. This feature isn't trying to solve that.
• Predictable, low-variance workloads: An internal dashboard with steady, modest usage is often better served by a fixed instance count with tuned vertical resources. Autoscaling adds value when demand actually varies.
   

How it works in practice

Consider an e-commerce application on a managed PostgreSQL database. On a normal weekday, one or two replicas handle the read load, with CPU sitting around 30-40%. 

Friday evening, a campaign goes live. What happens next:

• Traffic increases fivefold. As replicas absorb the extra read load, CPU climbs above 80%.
• Upsun adds a replica. CPU settles briefly, but traffic keeps growing.
• Another threshold breach. Another replica added. By peak, the pool has scaled from two replicas to six.
• No restart, no failover. Connection pools to existing replicas stay live. New replicas join the cluster and start serving traffic. Product pages, search, and the checkout funnel stay within expected latency.
• Overnight, traffic falls back. CPU drops below 20%. Upsun removes replicas one at a time, with cooldown windows in between, until the pool is back to baseline.

The next invoice reflects actual capacity used during the spike, not capacity sized for it ahead of time. The calendar reminder, the manual bump, the follow-up reminder to scale back down, all of it goes away.

Getting started

Setting up read replica autoscaling takes two layers of configuration:

1. Define the replica service in YAML

In your .upsun/config.yaml:

• Add a postgres-replica or mariadb-replica service
• Define a replicator endpoint on the primary
• Add a database-readonly relationship to your application

The PostgreSQL and MariaDB docs walk through the configuration in full.

2. Enable autoscaling for the replica

Turn on autoscaling for the replica service from either:

• Console: navigate to the environment's Configure resources tab.
• Upsun CLI: run the autoscaling:set command:
  upsun autoscaling:set --service db-replica1 --metric cpu

The settings match those for application and worker autoscaling:

• Scale-up and scale-down thresholds.
• Evaluation period.
• Cooldown window.
• Minimum and maximum instance limits.

Apps, workers, and managed databases on one platform, on one primitive, on one bill. That's what full-stack autoscaling actually means.

Further reading

If you don't already have a read replica configured, these resources provide a walk-through of the service definition. More on configuration, tuning, and related concepts:

If you don't already have a read replica configured, these resources provide a walk-through of the service definition. More on configuration, tuning, and related concepts:

• Autoscaling overview 
• PostgreSQL read-only replication
• MariaDB read-only replication
• Resource configuration