Introduction: Is All Data Better in One Place?

In modern data strategy, few ideas sound as intuitive as putting all your data in one place. One system. One source of truth. One architecture. Easier access, simpler management, and perhaps even a foundation for AI to work across everything.

But is this really a workable solution?

The assumption that all data should be centralized rests on a simpler assumption: that all data is fundamentally the same. But in reality, data comes with different structures, access patterns, performance requirements, and applications.

In a recent interview, our CTO Daniel van der Maas argued that the “everything in one place” philosophy can become a problem even though it sounds so reasonable. In this article, we’d like to delve deeper into a simple question: Is data centralization the most effective way to build a data ecosystem?

Data Is Not a Homogeneous Blob

One of the most persistent misconceptions in modern data strategy is that data can be treated as a single, homogeneous resource.

Consider the difference between satellite imagery and sensor measurements. One may consist of large binary files retrieved as complete objects. The other may arrive as a continuous stream of timestamped observations. They have fundamentally different access patterns and therefore different requirements for efficient storage and retrieval.

Liked what you read?

Subscribe to our monthly newsletter to receive the latest blogs, news and updates.

Join the Community

The same applies within geospatial data itself. Raster, vector, point clouds, meshes, and other spatial datasets can behave very differently depending on how they are created, updated, queried, and consumed.

Trying to force all of these into a single storage strategy inevitably introduces trade-offs.

A system optimized for one workload will rarely be equally optimized for another. And when organizations attempt to make one system accommodate everything, they can end up with an infrastructure that is adequate for many use cases, but exceptional for none.

The question, then, shouldn't be “where can we put all our data?” It should be “what does each type of data need in order to be useful?”

Infrastructure Doesn't Exist in Isolation

The second misconception is that data storage can be designed independently from the applications that consume it.

It can't. Period.

Different applications place fundamentally different demands on their data. Some require high write throughput. Others depend on complex analytical queries, low-latency lookups, immutable archives, or full-text search. These requirements naturally lead to different storage technologies and architectures.

This is particularly relevant as organizations increasingly connect spatial data to a growing range of workflows.

A dataset might be visualized in a GIS application, queried by a data scientist, consumed through an API, processed by an AI model, or used as part of an operational application. Each endpoint may interact with that data differently.

Yet the “everything in one place” approach effectively reverses this relationship. Instead of selecting infrastructure based on what applications need, applications are forced to work around the limitations of a predetermined storage strategy.

Over time, these compromises accumulate. Engineers build workarounds. Applications settle for slower performance. Data gets duplicated in ad-hoc ways. And what was supposed to simplify the architecture can ultimately make the ecosystem more difficult to optimize.

The Problem With “Good Enough”

The danger of these misconceptions is that they rarely cause an organization to fail outright. (Yes, that’s a danger!) 

A centralized system may work. Applications may eventually get the data they need. Teams find ways around limitations and processes continue moving. But working isn't the same as working optimally.

A modern data strategy therefore needs to look beyond the question of where data is stored and consider how that data will actually be used. In some cases, that may mean different storage technologies, different infrastructure, or even selectively replicating data to serve different workloads.

So the important question is whether the architecture is designed around the requirements of the data and the applications that depend on it. That is a conversation worth having before “good enough” becomes the default strategy.

Because the real goal of modern data infrastructure isn't to put everything in one place. It is to make the entire ecosystem work better.