Calculation performance: stored vs. unstored decision framework

Beginner

Apply a systematic decision framework to determine whether a calculation field should be stored or unstored, balancing find performance, data currency, and server load.

What you'll learn

The five conditions that force a calculation to be unstored
How stored calculations enable fast finds and sorts
The three-question decision framework for stored vs. unstored
Workarounds for time-sensitive values that must be findable

The stored vs. unstored decision is one of the highest-leverage choices in FileMaker schema design. A stored calculation can be indexed and found in milliseconds across millions of records. An unstored calculation is recomputed every time a record is displayed, consuming CPU and preventing indexing. The correct choice depends on what the field is used for and what its inputs are.

1/4

Five things that force a calculation unstored

FileMaker automatically marks a calculation unstored if it references any of the following. You cannot override this.

FileMaker Script

// These ingredients always produce an unstored calculation:

// 1. A related field
Sum ( LineItems::Amount )            // unstored

// 2. A global field
Globals::gCurrentUserRole            // unstored

// 3. A Summary field
SomeSummary                          // unstored

// 4. A Get() runtime function
Get ( CurrentDate )                  // unstored
Get ( AccountName )                  // unstored

// 5. Another unstored calculation field
UnsteredCalcField & " suffix"        // unstored (by inheritance)

Custom function recursion deep dive Case() vs. If() -- when to use each