Skip to content
← Back to the blog

Where your data lives: on your device or in the cloud?

When an application processes information, that work happens either on the device or on a remote server. Where it happens decides who can reach the data.

4 min read

Privacy · Data

When an app recognises a face in a photo, turns speech into text, or suggests the next word as you type, it is running a computation. That computation happens in one of two places: on the device in your hand, or on a remote server in the cloud. It’s a technical distinction with a very concrete consequence: it determines who can see your data.

In short. In the cloud, data is processed on servers run by a provider — with enormous advantages in scalability, but more points where information can be seen. On-device processing keeps data on the device: better for privacy, often more responsive, and able to work even offline. There’s no single right answer — but for personal data, local is usually the more respectful default.

Two places your data can live

Cloud computing, in the most widely used definition, is the on-demand availability of computing resources — processing power and storage — without the user managing them directly. NIST identifies five essential characteristics, including resource pooling and rapid elasticity: it’s what lets a service scale up and down with demand.

On-device (or local) processing does the opposite: data is handled directly on the device, without being sent to a server. It’s the most extreme form of edge computing, the model that “brings computation closer to the source of data” to reduce latency compared with a centralized data center. In some approaches, such as federated learning, the model travels to the data rather than the other way around: the raw information stays on the device.

Why local is better for privacy

This is where the difference weighs most. As the technical literature on edge computing notes, keeping and processing data “at the edge” makes it possible to increase privacy by minimising the transmission of sensitive information to the cloud; in doing so, ownership of the data shifts from service providers to users.

The contrast with the cloud is stark: when data sits on third-party servers, the provider can, technically, access it. That doesn’t mean it does so improperly, but every place where data is transmitted or stored is one more point to protect. The rule is simple: data that never leaves the device doesn’t have to be protected somewhere else.

Faster, and it works offline

Keeping computation close to the person using it has practical benefits beyond privacy. By avoiding the round trip to a remote server, local processing tends to be more responsive. It also reduces the bandwidth needed: running speech recognition on the device means sending text instead of an audio file, a notable saving in transmitted data.

Then there’s reliability: a system that processes locally can keep working even during an outage of the network or the cloud service. Real-world examples abound. According to Apple, basic dictation works directly on the device, even offline, on recent models; and the company states that recognising people in the Photos app happens entirely on the device, without sending the images to its servers. Google, for its part, was among the first to adopt federated learning in its Gboard keyboard: models improve while keeping typing data on the phone. To be precise: in federated learning what gets transmitted are model updates, not the raw data — a strong safeguard, but not a “nothing ever leaves the device”.

The honest trade-offs: scale, power, cost

It would be wrong to say “cloud bad, device good”. The cloud wins clearly on scalability: its elasticity lets resources grow or shrink in real time, something a single device can’t do, bounded as it is by its own hardware and battery. To train very large models or absorb sudden spikes, centralized infrastructure remains irreplaceable. The cost model changes too: the cloud shifts spending toward a pay-as-you-go model, while on-device leverages the power already in the device.

The conclusion, then, isn’t ideological but practical: it’s about choosing the right place for each job. And for personal data — the kind that reveals where we are, who we know, what we write — the right place is, most of the time, the device of the person who generated it. It’s the principle we follow when we design our applications.

Sources

Related insights