Size Limits & Doc Design Best Practices

3

Hey @James_Eades, welcome to the community and thanks for the mention!

I don’t know the whole picture of yours, but I believe there are ways to make Coda work bearably with over 20,000 rows (I have to believe — otherwise my work for my recent client would be a flop)

Here’s what you need to aim for:

  • Mostly scalar inputs in columns (i.e. numbers, strings, checkboxes, arrays of strings — NOT references or formulas)
  • No formulas that filter over the same table (directly or indirectly)
  • No buttons in this table. Build a separate single-row table to host a button and iterate instead
  • No conditional formatting — use something else to distinguish, e.g. a dedicated Status formula column with emoji
  • No unnecessary formatted text — flatten Format()s and Concatenate()s with .ToText()

Basically, these large tables should be plain fact tables (i.e. where one row registers one fact, e.g. one transaction of X money from user with ID=Y to user with ID=Z)

but yeah, sometimes it could be just better to use something else, like a traditional database, when you expect your app to work at scale