Where to start downsizing

Columns and types

Row archiving as a strategy moving forward

Other optimization resources


What does “calculations have been temporarily disabled” mean?

Things can be deleted or added and edits can be made, but Coda will not calculate the results of formulas. If a formula is changed for a column, the values in that column will not be updated to the new results until calculations are turned back on.

If I delete things from my doc with calculations disabled, will those deletions actually happen?

Yes, you can downsize your doc by deleting old rows, unused columns, and even remove things like conditional formatting. These deletions will all take place and help to downsize the doc to a level where calculations can be reenabled.

How do I get calculations turned back on?

There needs to be a significant enough decrease in the doc’s size to allow for calculations to catch up once they are turned back on. If you feel you have removed a good bit of rows, columns, and/or conditional formatting, please reach out to support and include the link to your doc.


When we talk about performance we’re usually referring to two separate but tightly connected things, Size and Speed. Each one affects the other and you’ll see that we discuss them both separately as well as together. There are no 100% answers when trying to optimize the two and there will always be a compromise on both sides.

A good metaphor is packing for a camping trip. The more gear you pack, the more comfortable you’ll be while camping, but this adds weight and means you will hike slower. The less gear you pack, the faster and farther you go, but you'll be a little less comfortable while camping. There is, and always will be, a trade off so the goal of this article is to provide the info you need to best assess your situation and preferences in order to provide the best solution.

Doc size refers to how much storage space a doc uses and is measured in megabytes (MB). This refers specifically to the size the doc takes up on our servers. We currently show this as a percentage of the limit in the doc warning you will see if your doc is approaching that limit.

So why does this matter?

The full doc is downloaded into your browser cache so that you can work in it even without an internet connection. But the bigger the doc size, the tougher it is for your browser to run it. If the doc grows big enough, it may become too big for your browser to load at all. This is why calculations might be turned off and why downsizing the doc is a good idea. We want to catch things before it’s too late.

Size Ranges

Over 99% of Coda docs are less than 20% on our doc size scale, slowness can start at 80%, and risk of not loading starts at 90%.

Where to start downsizing


The more columns you have in a table, the more space each row will take up. We have seen docs that run just fine with 100,000 rows and others that have trouble at 10,000 rows. It depends on your particular doc setup as to how many rows you can remove to bring the doc size down enough. As a ballpark starting point, you can use the percentage of your doc size as an indicator. If you have a 10,000 row table and you are at 99%, you will want to try removing 2,000 rows if your target is to get down to 80%.

After removing rows to bring your doc back down to a workable size, see row archiving as a strategy as one option to keep the doc size down moving forward.

Columns and Types

As a feature gets more advanced, so does the code it takes to store that features data. Each of the column types we have take up different amounts of space.


Buttons have the biggest storage “data chunks”. We have seen 10% to 50% savings in doc size when buttons are removed. This means big wins and easy to spot areas to adjust.

One strategy for keeping functionality and saving space are looking for buttons that are simply used as hyperlinks. These can be easily created as text links.

Another more advanced strategy is to use the RunActions() formula in place of any Push Buttons, or buttons that simply push other buttons. RunActions ↗️ allows you to create a comma separated list of button actions so you can combine the functions of multiple buttons into one. If you have a three button setup where one button pushes two others, combining these doesn’t necessarily mean you save 2/3’s the space, but it is roughly close. So this is another big win that doesn’t have any end-user cost.

Conditional Formatting

Remove conditional formatting from big docs has saved anywhere from 10% to 50% of the doc size.

What makes this a first place to look for optimizing a doc, is that many times, using the text stying from the text toolbar is sufficient and accomplishes nearly the same result as the conditional formatting rule. This text styling will also flow through and show in Lookups, which is a big part of where formatting is used. So we get very close to the same result with a big savings in storage space.

You’ll have to assess each doc and situation individually, but this is another great place to start.


If you have a lookup column that returns many row values per cell, it’s possible that this is taking up a lot of space in your overall doc size. Lookups are a powerful feature in Coda, but when used to an extreme and returning 100’s of values per row, they can cause the column size to grow fairly large. Removing columns like this or finding a different strategy can help both speed and size performance in the overall doc.

Dates and Times

Dates and Times are a little bigger than text strings because they have some formatting code with them. This is pretty negligible and not really worth using text strings instead. Over thousands of rows, you’d save a percentage point or two and would have to make up for it by forcing these text strings into dates and times for any formulas.


Checkboxes add a little bit of weight being shown as actual checkboxes. The underlying values are still “true” or “false”, but styling and interactivity requires a little bit more to make it happen. In a big doc with thousands of rows and a checkbox column, you can save a percentage point or two by changing this column to text and using “true” and “false” instead. So you lose a lot of styling and functionality making it not really worth what you gain in storage space.

Text and Numbers

Text Strings and Numbers have the smallest storage footprint. They are pretty much what you type and that’s it. A little bit more code is needed to store styled text, but it’s still relatively close to what a string of text or a number would be by itself.

Row archiving as a strategy moving forward

We’ve discussed the size differences in various column types and have seen that more complex types take up a good bit more space. Another truism is that more columns take up more space than less columns. The two bits of information can help us develop possible archiving solutions that can save space while retaining relevant data for the customer to reference.

Bigger docs tend to have tables with many columns. This is very useful when you’re needing to filter and compile data based on the individual data points in those columns. But after a project is done, this can be overkill for most situations. You’re likely looking to maintain a summary of a project and maybe a data point or two for reference.

Let’s say you have a project table with 100 columns of various data points. When that project is marked as complete, maybe you only need to know the summary, the date, a customer sentiment rating, and the project lead. This gives us 5 columns if we include the project title as it’s own column.

In the summary column of this new archive table, we can include the items from the other original columns, but stored as text instead of separate data points. With some creativity using Concatenate() or Format() you can create all sorts of summary write up styles that combine everything into one text field, so not really any data loss, simply sacrificing some rarely used filtering capabilities on individual columns for a big savings in storage size.

So in the end we can bring that 100 column table that is monstrous to look at down to 5 simple, targeted, and very easy to grok columns. This is both beneficial for the doc as well as the customer. One of Coda’s biggest strengths in offering the functionality and layout options that it does, is allowing you to clear away the clutter and whittle your data down to the few items that require the most focus and the most benefit.

Other optimization resources

Improving performance

Troubleshooting memory issues

Troubleshooting calculation performance issues

Optimizing slow formulas in your doc

Using Debug Tools

Did this answer your question?