Data has gravity
Systems don't grow around code. They grow around where the data lives.
Draw an architecture diagram of any mature system and you will find that the boxes cluster. Services huddle around the databases they read from. Teams huddle around the services they own. Over time, the shape of an organisation starts to look suspiciously like the shape of its data.
This is data gravity. The more data accumulates in one place, the more expensive it becomes to move, and the more everything else bends toward it. Code is light; you can rewrite it in a weekend. Data is heavy. It carries history, references, assumptions baked into its shape that no one wrote down.
Where you put data first is a long decision
Early in a project, choosing where data lives feels like an implementation detail. It is not. It is the closest thing software has to choosing a city's location. You can rebuild the streets later. You cannot easily move the river.
This is why schema design deserves more care than almost any other early decision. A clumsy function costs you an afternoon. A clumsy table costs you every query, every migration, every service that touches it, for as long as the product exists.
Design for the move you hope never to make
You cannot avoid gravity, but you can avoid being trapped by it. Keep identifiers stable and meaningless. Keep the boundaries between datasets explicit, so that a future split is a matter of drawing a line that already exists rather than discovering one. Record why a field exists, not just what it holds.
Integrations are where gravity bites
Gravity is most visible at the edges, where your system meets someone else's. Every external integration is an agreement between two bodies of data with different shapes, different identifiers and different ideas about what a single record means. One system's shipment is another's container, and a third's line item.
The temptation is to translate at the boundary and move on. The better move is to treat the translation itself as a first-class part of the system: versioned, logged and owned. When an upstream system changes a field at short notice, and it will, the difference between a quiet fix and a week of confusion is whether anyone can see exactly what was mapped, when and why.
Multi-tenant systems amplify all of this. When many organisations share one schema, every column is a promise to all of them at once. A field added for one tenant becomes a field every tenant carries. Tenancy boundaries, like data boundaries, are cheapest to draw on day one and most expensive to retrofit.
The goal is not to make data weightless. It is to make sure that when something finally needs to move, you can still lift it.