In Vendor lock-in: not even once, I wrote about keeping your data portable while choosing how much infrastructure management to hand over. Databases make that tradeoff particularly interesting. You want room to grow, but you also want to be able to leave.
Suppose your application needs one very large database. You can’t split customers into independent databases, with each handling a smaller workload. What I call natural scaling doesn’t fit your application.
At some point, distributing data and writes across machines becomes attractive. Managed distributed databases can take on work such as sharding and rebalancing for you. That convenience can come with substantial costs and dependencies on a provider’s implementation. PostgreSQL wire compatibility alone doesn’t make those dependencies disappear.
Automatic sharding isn’t exclusive to proprietary technology. Open source solutions exist, too. The question is how much operational complexity you want to take on, and what you’d need to replace if you moved.
Upsun’s approach is to keep your data in familiar open source databases such as MariaDB and PostgreSQL. That leaves a useful question: how far can you scale those databases before you need a different architecture?
Quite far already. And now there’s another step: native autoscaling for their read-only replicas.
Yes, the title takes a small liberty. “Database autoscaling” can mean several different things. Here, it means automatically adding and removing read replica instances as demand changes. Writes still go through the primary database.
First, give the database room to work
Before distributing queries across several machines, you can give one database more resources. More CPU helps with concurrent query execution. More memory lets it keep more frequently accessed data and indexes in cache.
Upsun’s Guaranteed CPU sizes go up to 64 vCPUs and 512 GB of RAM with the high-memory profile.
That’s a substantial amount of capacity for a single database. How much traffic it handles depends on your queries, indexes, storage, and concurrency. An inefficient query can still make an expensive machine very busy.
Vertical scaling gives you room to grow while keeping the same database architecture. But eventually, you may find that much of its CPU time goes toward answering reads.
Then, move reads onto replicas
A product listing, a dashboard, or a reporting job often needs to read data without changing it. Those queries don’t all have to compete with writes on the primary.
Upsun supports read-only replicas for MariaDB and PostgreSQL. Each replica maintains a copy of the primary’s data and has its own resources to execute queries.
Your application directs suitable reads to the replica connection. The primary continues handling writes and supplying replication data, while the replicas take on some of the query work.
For an application that spends much of its database CPU serving reads, this can make a considerable difference. You can size the replicas for that work, independently of the primary.
There are two details your application needs to account for. Creating replicas doesn’t automatically route read queries to them. And replication is asynchronous, so a replica can lag behind the primary. A read that must see a write immediately should use the primary.
Replicas also need resources to apply changes. Replication adds work to the primary, too. The benefit comes from moving enough read work off it to make that worthwhile.
Now, let the number of replicas follow demand
The next step is letting a replica service run multiple instances and adjusting that count automatically.
Picture an application used throughout the working day. At 9 a.m., people sign in, open dashboards, and browse records. Read traffic grows through the morning. After 5 p.m., it drops, and overnight the application is quiet.
With autoscaling, sustained CPU usage above your configured threshold can trigger additional replica instances. As demand falls, the platform can remove instances, within the limits you set.
The primary still processes writes and replication. The growing volume of read queries can use the extra replica capacity, instead of all landing on that same primary.
This follows measured resource usage, rather than a timetable. A busy evening can keep capacity in place. A quiet morning doesn’t need the same number of instances as a busy one.
More capacity with the databases you already use
You now have three complementary ways to grow: give each database more resources, move suitable reads to replicas, and let replica counts follow demand.
The primary’s write capacity remains a limit. Applications that outgrow it may still need partitioning, sharding, or a different database architecture. For workloads dominated by reads, though, there is a lot of useful capacity available before that point.
Your data stays in MariaDB or PostgreSQL, accessible through their standard clients and tools. Moving providers still means replacing platform configuration and automation, but this feature doesn’t require adopting a proprietary database engine.
That’s what excites me about this release. You can take an existing application further with familiar databases, while the platform handles changes in replica count throughout the day.
To try it, configure your read replicas and direct suitable queries to them, then enable autoscaling with thresholds and limits that fit your workload. Last modified on November 5, 2026
Dispatch
Cloud