Ask a mobile team why it’s still on a VPS two years after launch and the honest answer is often some version of “we thought it was our code.” Stubbornness has very little to do with it. A virtual private server that’s starting to struggle rarely throws a clean error or points at one culprit. The team sees variance instead, a backend that feels quick on Monday evening, sticky on Tuesday and perfectly fine again by the time anyone opens the logs. That’s why this column treats unpredictability, more than raw traffic, as the better trigger for moving, even though traffic is the number most teams actually watch.<\/p>\n\n\n\n
The five signs that follow are ranked by the damage they tend to do, and several of them first look like a bug the team wrote itself. No single sign proves that a move is due, although two or three turning up in the same quarter usually point that way.<\/p>\n\n\n\n
Start with the sign that costs the most, which is latency nobody on the team can reproduce. The averages look fine and every dashboard is green. That’s exactly why the support inbox feels so baffling when it fills up with screenshots of a spinner that never quits, often from the same handful of users at roughly the same hour. Underneath any VPS sits a physical machine you share with strangers, along with its processor cores, its caches, its memory bandwidth and the network card all of you push traffic through. If one of those strangers kicks off a heavy job, your requests can end up waiting in line behind it. Worse, a slow call inside an app has a habit of not staying rare. Research on large web services worked out how a one-in-a-hundred delay becomes the normal experience<\/u><\/a>\u00a0once a single request has to wait on many servers before it can finish.<\/p>\n\n\n\n Think about what a typical home screen asks the backend for. There’s the feed, the profile and a badge count, plus whatever the designers bolted on last sprint, and together they can easily add up to ten separate requests before anything appears. Give each of those calls a one percent chance of hitting a bad moment and roughly one screen in every ten stalls (the arithmetic is unkind that way), while no individual request looks guilty enough to chase. Teams then spend weeks rewriting database queries that were never the problem. That lost time is arguably the real price of this sign, because it goes to the wrong suspect while frustrated users drift off to a competitor.<\/p>\n\n\n\n There’s a cheap test before anyone rewrites anything. Linux counts that waiting as steal time, the slice of processor time handed to other virtual machines<\/u><\/a>, and many monitoring tools can graph it. Put that line next to the slowest one percent of response times for a week, across busy evenings as well as quiet nights. If the spikes line up, the code is probably innocent, and query tuning is unlikely to change much about what the shared hardware is doing.<\/p>\n\n\n\n When the steal line and the slow requests do move together, the case for single-tenant hardware gets hard to wave away. Atlantic.Net<\/u><\/a>‘s bare metal hosting<\/u><\/a>\u00a0rents an entire physical server to one customer, with no virtualization layer sitting between the app and the processor and full administrator access to the machine. None of that turns a slow query into a fast one. It does remove the neighbor, so when the slowest requests start to drift, the cause is far more likely to sit somewhere the team can actually inspect.<\/p>\n\n\n\n A short detour into the name helps explain why the problem catches so many teams out. The word “private” in virtual private server has always described the software, the walled-off operating system you log into and configure. The hardware was never private. Plenty of teams spend years reading the first meaning as if it promised the second.<\/p>\n\n\n\n Close behind comes a database that wants the whole machine. Most early backends put the server code, the database, a job runner and often a cache on one VPS, and at launch that’s a sensible call. The memory guidance for one of the most widely used open-source databases<\/u><\/a>\u00a0frames its starting advice around a dedicated database server and suggests giving its cache roughly a quarter of the system’s memory. It also expects the operating system’s own file cache to carry part of the load. On a crowded VPS, that file cache is often the same memory the rest of the backend is already chewing through.<\/p>\n\n\n\n Anyone who has read how a mobile backend divides its work<\/u><\/a> knows the database is meant to be the steady part, the store for profiles and purchase history while the application code fields requests. Put it on a shared box, though, and the database can end up as the loudest tenant on its own server. Picture the nightly cleanup kicking in at 2 a.m. in one time zone, which happens to be lunchtime for users somewhere else, or a single oversized sort spilling onto the disk. Every request queued behind that work waits, and from the outside the stall is hard to tell apart from the neighbor problem in the first sign.<\/p>\n\n\n\n Two numbers are worth pulling before any move. The first is how large the frequently read part of the data has grown compared with the memory the database actually gets. The other is easier to dig up, the number of times the team asked for more memory over the past year. Each request is small and easy to approve, which is probably why nobody adds them up.<\/p>\n\n\n\n Here this column has to argue partly against itself. Giving the database its own, larger VPS often does fix the symptom, and for a lot of apps that’s the correct next step, full stop. How long the relief lasts depends mostly on how fast the data grows. Once the bigger plan reaches the same ceiling, the team is back to resizing whenever the database demands it, on a calendar nobody chose.<\/p>\n\n\n\n Teams that handle this well tend to give the bigger VPS an expiry date, much like a lease. They write down the memory and response-time figures that would justify the next move, then put a reminder in the calendar six months out so someone actually checks those numbers. Skip that note and the next resize tends to get decided at 3 a.m. during an incident, and nobody picks hardware well at 3 a.m.<\/p>\n\n\n\n The third sign arrives the day the app starts handling data that someone regulates. A fitness app that signs its first clinic as a customer and begins storing patient records on that clinic’s behalf has stepped into US health privacy law, whether or not anyone planned it. Federal guidance leaves little room here, since a host that stores health records counts as a business associate<\/u><\/a>\u00a0even when it holds only encrypted copies it can’t read. That host has to sign an agreement accepting legal duties, and a plan picked for its monthly price may not come with one.<\/p>\n\n\n\n Staying away from clinics doesn’t take a health app out of scope either. In 2024 the FTC reworded its definitions so nobody could miss that its breach notification rule covers health apps that HIPAA doesn’t reach<\/u><\/a>. The service providers behind such an app, the hosting company included, have to warn the app maker once they discover a breach. If 500 or more people are caught up in it, the app maker owes the FTC a notice too, inside the same 60-day window it has for telling users.<\/p>\n\n\n\n The practical work starts with a map of where health information actually travels. It rarely stays in the main database, and copies tend to turn up in logs and crash reports, or in backups nobody has opened in months. Every one of those locations sits on someone’s hardware. Ask the current host whether it will sign an agreement that covers all of them, and for exactly which of its products. A vague reply often means the cheap plan isn’t covered. The same federal guidance also notes that keeping records on servers abroad may raise the risks, which is worth knowing when a budget plan’s cheapest region sits on another continent.<\/p>\n\n\n\n Payments raise the same issue from another direction. A team working through the compliance steps for a peer-to-peer payment app<\/u><\/a> runs into identity checks and the card industry’s security standard well before launch. Nothing in either rulebook bans a VPS, and this column won’t pretend otherwise. The health regulator itself notes that the type of cloud setup can affect the risk analysis a company has to perform, and the same reasoning tends to carry over once money is moving through the app.<\/p>\n\n\n\n Business customers bring their own version of the question. Once an app sells to companies, security questionnaires start arriving, and plenty of them ask for SOC audit reports<\/u><\/a>, which exist to help customers judge the risks of outsourcing a service. A buyer reading one will often want to know what the vendor’s own host can attest to as well. Keeping a one-page note on where the backend runs, who owns the hardware and what the host has been audited for tends to shorten every questionnaire that follows. Once the hosting contract becomes a document an auditor reads, single-tenant hardware tends to turn a long argument about shared infrastructure into a short one.<\/p>\n\n\n\n Fourth on the list is a disk that fills faster than the user count climbs. On a single VPS, every profile photo and ten-second clip lands on the same volume the database lives on. Serving them back out isn’t free either, because plenty of VPS plans meter monthly transfer, and a video one user replays five times counts against the cap five times. The direction of travel isn’t subtle. The Ju<\/u><\/a>n<\/a><\/u>e 2026 edition of Ericsson’s Mobility Report<\/u><\/a>\u00a0found uplink traffic growing faster than downlink at 43 of the 55 service providers it measured, with user-generated content and cloud storage among the main drivers.<\/p>\n\n\n\n Strictly speaking, this sign is half a false alarm. Before blaming the server, try moving uploads and backups into cloud storage<\/u><\/a> and leaving the machine to run code and hold live data. Start with the backups. One that sits on the same disk as the database it protects can go down with that disk, which rather defeats the purpose.<\/p>\n\n\n\n The false alarm turns real once the app starts working on those files. Resizing images and converting video are heavy, bursty jobs, and on a shared machine they drop straight back into the first sign. Automated checks on uploaded images tend to run when users are most active, because that’s when the uploads arrive. The neighbor problem returns, only this time the noisy neighbor is the app’s own upload queue. A regular look at the transfer meter, set against the plan’s cap, can give months of warning before this sign turns expensive.<\/p>\n\n\n\n Last, and easiest to ignore, is the number of servers. A backend that began as one VPS tends to become five, split across the API, the database, the job workers, a staging copy and something an early engineer set up that everyone is now afraid to reboot. In fairness, each of those servers probably solved a real problem the week it appeared. Add them up, though, and the result is a system no one actually designed, kept alive by a deployment script and by whichever engineer still remembers what the fifth box is for.<\/p>\n\n\n\nOne Tenant, One Machine<\/h2>\n\n\n\n
A Database That Wants the Whole Server<\/h2>\n\n\n\n
When a Bigger VPS Is Enough<\/h2>\n\n\n\n
Health Data Changes the Hosting Contract<\/h2>\n\n\n\n
Payments and the Security Questionnaire<\/h2>\n\n\n\n
Uploads That Outgrow the Disk<\/h2>\n\n\n\n
Five Servers Nobody Designed<\/h2>\n\n\n\n