- A page in a real app asks its database several questions in a row, and each one pays the distance between them.
- Hosting the app in one place and the database in another is common, and the distance between them is rarely chosen on purpose.
- For one of our customers, putting the app in the same city as its database took their slowest page from 7.6 seconds to 0.42.
When an app is slow, people usually blame the code or the server. Often the problem is neither. The app is running in one city, its database is running in another, and every page has to wait for questions and answers to travel between the two.
Nothing on any dashboard shows this. Both services report green, and the app is just slow.
How apps end up far from their data
Nobody plans to put an ocean between an app and its database. It happens one reasonable decision at a time.
These days the app and the database usually come from different companies. You sign up for a hosted database, and it asks for a region or picks one. Later you deploy the app somewhere else, and that platform picks its own region. In development it all feels fast, because the database is on your laptop or you're the only user. In production, every page that leans on the database gets slower.
The usual response is a bigger server. That doesn't help, because the server isn't what's slow.
What it looked like for one of our customers
Creator Flow is an Australian marketplace that connects brands with content creators. They're a Roar AI customer and host their app on our platform, while their database runs separately, in Sydney.
Their app was running in Singapore. Their creator search page, the one people use most, was taking 7.6 seconds to load. The server had plenty of headroom, so we looked at where the database was instead. We moved the app to Sydney, into the same city as its database, and measured the same pages on both setups.
| Page | App in Singapore | App in Sydney | Faster by |
|---|---|---|---|
/find-creators (heavy database use) | 7.6 s | 0.42 s | 18× |
/blog (database) | 0.89 s | 0.12 s | 7× |
/ (home) | 0.23 s | 0.09 s | 2.4× |
/creators | 0.23 s | 0.08 s | 2.9× |
After we put the application and the database together, response time on creator search fell from 7.6 seconds to 0.42. We didn't isolate every variable, so we won't claim distance accounts for every millisecond. But the pattern is clear: the pages that lean hardest on the database improved the most, and the pages that barely touch it improved the least.
Why distance costs this much
A round trip between Sydney and Singapore takes about 95 milliseconds. Between an app and a database in the same data centre, we measure about 0.3 milliseconds.
95 milliseconds is nothing for one question. The trouble is that a page is rarely one question.
A page is a conversation, not a request
To show one page, an app usually asks the database a series of things. Who is this user? What are they allowed to see? Which products match the search? Then, for each product, its price, its stock, its reviews. A lot of these depend on the answer before, so they go one after another.
Modern frameworks make this easy to miss. A line of code that looks like it reads one list can ask the database once per item in that list. On a laptop that costs nothing, so nobody notices, and that includes an AI assistant writing the code.
If the queries run one after another, the waiting adds up like this:
| Queries per page (sequential) | Same data centre (~0.3 ms) | Sydney to Singapore (~95 ms) |
|---|---|---|
| 1 | 0.3 ms | 0.1 s |
| 10 | 3 ms | 1 s |
| 50 | 15 ms | 4.8 s |
This assumes every query waits for the one before it. Queries an app sends in parallel don't stack up like this, and good code sends as many in parallel as it can. But a lot of real code doesn't, and the default habits of most frameworks make it sequential.
On top of that, opening a new secure connection to a database takes several round trips of its own. Setups that open a fresh connection on each request pay that every time.
Matching regions helps, if you remember
Two providers in the same region can be very close, and if you're staying with two providers, matching regions is the single most useful thing you can do. The risk is that the match is something you have to remember. Each new environment or database is another chance to get it wrong. Running across providers also makes private networking harder to set up, so it's common to see a database left open to the internet when it didn't need to be.
The industry has noticed
For a while, the popular advice was to run code as close to the visitor as possible. That works well for pages that need little data. For database-heavy pages, the industry has increasingly recognised that it isn't always the right trade. Vercel, for example, now tells customers to run functions in the same region as their data, and its CTO has said that an application's real logic "has to run close to the data".
When it doesn't matter
Locality is not always the problem, and we don't want to pretend it is.
- A site that barely uses a database (a brochure site, a blog served from a cache) won't notice. One or two queries per page across a long distance cost a fraction of a second.
- If your visitors are the far thing, put the app and the database together near them. A visitor reaches your app once per page, while your app reaches its database many times. Spend the distance where it is paid once.
- If you have to stay split, match regions, combine related queries, run independent queries in parallel, keep database connections open, and cache what you can. Each helps, and none helps as much as removing the distance.
How we think about it at Roar AI
On Roar AI, we keep an app and its database together on purpose. When we host the database, it runs in the same data centre as the app. In a region where we can't put a database beside the app, we don't offer one there at all, rather than serving it quietly from another country.
The point isn't really speed. It's that you shouldn't have to know any of this. Where your database lives relative to your app should be decided once, correctly, by the platform, and not rediscovered by you when a page gets slow.
If your app feels slower in production than it did on your laptop, check where its database is before you buy a bigger server. And if you'd rather not have to think about it again, that's what we do.