Skip to content

Calculated fields

A calculated field is an extra column on a model table, defined by a SQL expression over that table’s own columns. It behaves like any other field — draggable into charts, filterable, aggregatable — and is marked with a ƒx pill in the field tree.

Two places, same result:

  • In the model editor, click a table’s field to open the field panel, then Add Calculated Field.
  • In the dashboard field tree, use the per-table ƒx → New calculated field shortcut while you’re building a chart.
Setting Meaning
Field name how it appears in the field tree
Expression a SQL expression over this table’s columns (an Insert column helper types the references for you)
Result type number, integer, decimal, string, boolean, date, datetime, time, or geo
Default aggregation what charts do with it by default: none, sum, avg, count, count distinct, min, or max

A Validate button checks the expression server-side before you save.

Expressions run in your source database, so use its SQL dialect. Two rules:

  • Read-only — no subqueries, no DML.
  • Guard division: SUM(revenue) / NULLIF(SUM(cost), 0) avoids divide-by-zero errors.

Row-level or aggregate both work — a row-level expression (say, price * quantity) pairs with a default aggregation like sum, while an aggregate expression (like the margin example above) uses aggregation none.

You want… Use
A new column on one table — string cleanup, categorization, row math Calculated field
A reusable number that respects filters, compares time periods, or computes % of total across tables SquareX measure

Rule of thumb: if the logic makes sense per row, it’s a field; if it only makes sense per group — and especially if it needs Calculate, Fixed, or time intelligence — it’s a measure. (SquareX will even tell you: putting row-level logic in a measure fails with SQX014, pointing back here.)

One limitation: calculated fields can’t be used as relationship join keys.