Base Properties vs Computed Properties: Store the Source, Derive the Rest

When to store a value directly versus calculate it on read. The rule is boring and absolute: store what you can't recompute, compute everything else.

The only question that matters

Can you reconstruct this value from data you already store? If yes, it is computed — full stop. If no, it is base. Everything else is rationalization. People store age next to birthday because 'reads are faster,' then ship a system where half the users have a stale age because nobody ran the nightly job. You didn't save a read; you bought a correctness bug with a delayed fuse. Base properties are the irreducible inputs: the price a customer agreed to, the timestamp an event occurred, the bytes an upload contained. They have no upstream, so they must be stored. Computed properties are pure functions of those inputs: total, age, slug, display name, status. They have an upstream, so storing them duplicates truth. Duplicated truth always diverges. The question is never 'which is faster,' it's 'which one can lie to me,' and the stored derivation always can.

Where base properties earn their keep

Don't let the bias against denormalization turn into zealotry. Base properties win whenever the input is genuinely irreducible — and a surprising amount of data is. A historical price is base, not computed, even though 'price = quantity × unit_price' looks derivable: the unit_price changed last Tuesday and the order must remember what was true at purchase time. This is the classic trap — snapshotting a value at a moment makes it base data, because the 'computation' would now produce a different, wrong answer. Audit logs, ledger entries, signed contracts, captured API payloads: all base, all sacred, none recomputable. The test is temporal. If recomputing today would betray what was true when the fact was recorded, it is not a computed property pretending to be base — it is base, and treating it as computed is how you erase history and fail an audit.

How computed properties knife you anyway

Computed isn't free, and I won't pretend otherwise. The failure mode flips: instead of staleness you get cost and recursion. An ORM computed property that fires a query per access turns one page render into 200 N+1 queries. A computed field that depends on another computed field that depends on the first is a stack overflow waiting for a deploy. And 'derived on read' across a network — recomputing a dashboard aggregate on every request — is how you DDOS yourself with your own elegance. The discipline is: compute by default, but know your access pattern. Cheap and local (string concat, a subtraction)? Compute inline, always. Expensive and hot (cross-table sum read a thousand times a second)? Cache the computation with explicit invalidation tied to its inputs. That is still a computed property. What it is NOT is a hand-maintained base column you update in seven different code paths and forget in the eighth.

The verdict, stated plainly

Store the source, derive the rest. Base properties for inputs with no upstream and for snapshots whose truth is frozen in time. Computed properties for absolutely everything that can be expressed as a function of data you already hold. When performance forces your hand, you don't promote a computed value to a maintained base field — you cache the computation behind an invalidation rule keyed to its inputs, so there's still exactly one source of truth and one place it can be wrong. The teams that get burned are the ones who store derived values 'for convenience' and discover, six months in, that convenience meant 'a second copy of the truth that nobody keeps current.' Every hand-synced denormalization is a chore you signed up for and will eventually skip. Computed wins because it makes drift structurally impossible. Base exists because some facts have no formula. Mix them on that line and nowhere else.

Quick Comparison

Factor	Base Properties	Computed Properties Store The Source Derive The Rest
Source of truth	IS the source — irreducible input	Derives from existing data — zero duplication
Risk of going stale	None; it's the canonical value	None if computed on read; cache needs invalidation
Read cost	Cheap — just a lookup	Can be expensive; N+1 and recompute traps
Historical/temporal correctness	Correct — snapshots freeze truth at a moment	Dangerous — recompute betrays what was once true
Maintenance burden	Manual sync across every write path = drift	One function, one truth, no sync chores

The Verdict

Use Base Properties if: The value is raw input you cannot derive from anything else — a user's birthday, a price entered at checkout, an external API response, a UUID. Base properties are the floor; something has to hold the actual data.

Use Computed Properties Store The Source Derive The Rest if: The value is a function of other values you already have — age from birthday, full_name from first+last, cart total from line items, isExpired from a timestamp. Compute it and never let it rot.

Consider: Memoized/cached computed properties when the calc is genuinely heavy (aggregations over millions of rows, hashing). That's still computed — you're caching the derivation, not promoting it to a hand-maintained base field with no invalidation story.

Base Properties vs Computed Properties Store The Source Derive The Rest: FAQ

Is Base Properties or Computed Properties Store The Source Derive The Rest better?

Computed Properties is the Nice Pick. Computed properties have exactly one source of truth, so they can never drift out of sync — the single worst bug class in stateful systems. Base properties are mandatory for raw inputs, but every derived value you store by hand is a denormalization you now have to babysit. Default to computing; reach for a stored base value only when the input is irreducible or the computation is provably too expensive to repeat.

When should you use Base Properties?

The value is raw input you cannot derive from anything else — a user's birthday, a price entered at checkout, an external API response, a UUID. Base properties are the floor; something has to hold the actual data.

When should you use Computed Properties Store The Source Derive The Rest?

The value is a function of other values you already have — age from birthday, full_name from first+last, cart total from line items, isExpired from a timestamp. Compute it and never let it rot.

What's the main difference between Base Properties and Computed Properties Store The Source Derive The Rest?

When to store a value directly versus calculate it on read. The rule is boring and absolute: store what you can't recompute, compute everything else.

How do Base Properties and Computed Properties Store The Source Derive The Rest compare on source of truth?

Base Properties: IS the source — irreducible input. Computed Properties Store The Source Derive The Rest: Derives from existing data — zero duplication. Computed Properties Store The Source Derive The Rest wins here.

Are there alternatives to consider beyond Base Properties and Computed Properties Store The Source Derive The Rest?

Memoized/cached computed properties when the calc is genuinely heavy (aggregations over millions of rows, hashing). That's still computed — you're caching the derivation, not promoting it to a hand-maintained base field with no invalidation story.

The Bottom Line

Computed Properties wins

Computed properties have exactly one source of truth, so they can never drift out of sync — the single worst bug class in stateful systems. Base properties are mandatory for raw inputs, but every derived value you store by hand is a denormalization you now have to babysit. Default to computing; reach for a stored base value only when the input is irreducible or the computation is provably too expensive to repeat.

Related Comparisons