How I Think About Database Design Before an App Gets Big

While designing a simulation-heavy application, I started thinking about what would happen if every user had their own version of thousands of objects that changed over time.

The naive solution is easy: copy everything for every user and update it whenever something changes.

It also sounded like a good way to create an enormous number of database reads and writes.

That made me think more carefully about which data really needs to be stored.

A useful distinction is between base data, user-specific changes and data that can be calculated again.

If a player starts with the same attributes for everyone, I do not necessarily need a complete independent copy for every user. I can keep the shared base data once and store only the differences that belong to a particular user.

The same applies to simulation results. If something can be reproduced deterministically from known inputs, storing every intermediate state may be unnecessary. For other data, occasional snapshots can be much cheaper than continuously writing the entire state.

So instead of:

complete copy of everything for every user

I can think in terms of:

shared base data
+ user-specific changes
+ periodic snapshots where useful

I am not trying to optimise a database for millions of users before I have them. That would be another kind of mistake.

But asking “does this really need to be duplicated and stored?” early on can prevent an architecture where the amount of data grows much faster than the product itself.