PSA: The hidden cost of Checkbox column for true/false values

Note: This applies to you if you’re a power user who builds large complicated docs AND also need to access those via API (incl. Zapier or Cross-doc), and had already hit the current 125 megabyte API access limit in the past. If you are a regular Coda user who have never experienced these kinds of problems, please don’t apply what’s described below.


When I build my docs, I exclusively use Checkbox columns to display logical (on/off, true/false) data, even if those are formulas and not clickable controls. I was optimizing a doc recently and discovered the hidden cost of using such columns (also not just Checkboxes but any controls).

Here are the “before” and “after” versions of a row from the same table:

The difference is that in the “before” there are four Checkbox columns, and in the “after” it’s the same four logical columns but with their type changed to Text.

That’s ~150 bytes saved per row per column changed for regular tables, and even more for crossdoc tables (since the valueRefs part is much longer there).

Note that the values will still be logical true/false, not the "true"/"false" strings. I.e., they will test positively for .isLogical(). So it’s safe to keep using those in formulas; this column type change doesn’t affect anything but the way these are stored and displayed.

Again, this is a last resort measure. I did this today because I had to get our doc below the 125 MB API limit quickly so that its data could cross-doc to other docs. Don’t do this unless you absolutely have to. Remember that good user experience comes first, and premature optimization is a bad practice.

1 Like

That is super valuable information. Thank you! I’ve also recently learned that the other hidden cost to checkboxes is that if you ever decide that you want to switch to more than one state (i.e. a selector) it can cause you to lose your CreationDate information, which can be really annoying!