10 min read

Coda at scale: Managing row count

Explore the considerations and challenges associated with large Coda tables.

In this guide, we explore the challenges and considerations associated with large Coda tables. We’ll explore the limits of Coda’s data storage and show you a few tips to keep row counts in check and your doc running smoothly.

What you'll learn:

What determines row limits.
How to reduce row counts.
Scalable ways to keep row counts in check.

What you'll use:

Tables and views
Pack queries
Concatenate() (for archiving)

1. How many rows can a table have?

The answer is, it depends on the size of the columns in each row. Let us explain. Table size refers to how much storage space a table uses and is measured in megabytes (MB). This refers specifically to the size the table takes up on our servers. But why does this matter? When you open a Coda doc, the full doc (including the tables) is downloaded into your browser cache so that you can work in it even without an internet connection. As your doc size grows, so too does the amount of work it takes for a browser to run it. As you approach your browser’s size limits, you may start to experience longer loading times, especially on mobile browsers, which have lower capacities. If a table in your doc grows big enough, the doc may exceed your browser’s size limit, preventing it from loading it at all. The size of a table is impacted by 3 factors:

Row count - the number of rows in a table.
Column count - the number of columns in a table.
Column content - the complexity of what is stored in each column. Static text would be simple, formulas would be more complex.

It may be helpful to think about table size as an equation: row count x column count x column content = table size How may rows you can have depend on how many columns you have and what are in each column. We’ve seen docs that run just fine with 100,000 rows and others that have trouble at 10,000 rows. Tables with low column counts or simple column content will be able to accommodate higher row counts before experiencing performance issues. Learn more about doc size and performance here.

2. Why row counts grow

Row counts grow large for a number of reasons, but we see a few situation arise most often:

Immortal rows

Problem: Immortal rows are rows that are created, used, and then left in the table forever. We often see these immortal rows in trackers. When you mark a row as "done", where does it go? Is it just hidden from the main views but still remains in the main parent table forever? Over time, these "done” tasks keep piling up.

Solution: Do a cleanup and delete any rows that you are sure you won't need anymore. If that doesn't reduce the number of rows enough, or if you want to keep a record of old rows just in case, consider archiving them. Row archiving leverages the table size formula (row count x column count x column content = table size) to reduce table size without reducing row count. To archive, combine column content into summaries and move old rows to a new table with fewer columns. Fewer columns means you can safely support more rows. Learn more about archiving here.

Broad pack queries

Problem: Pack sync tables are great for automatically bringing in information from other tools. But the problem is that they often bring in everything instead of just the information you actually need. Users end up applying filters in Coda to narrow down the huge tables and see only what they really want. Solution: If you have a sync table that is pulling thousands of rows of data, consider if you need every one of those rows in this specific doc. Can you change the sync parameters to pull a narrower list of data points? Consider restricting the sync by project, date, or status to see if any extraneous rows can be excluded. If you are already adding Coda filters to the table, seeing if you can put those parameters into the search query is a great place to start. Alternatively, consider limiting the columns that are being synced (remember, fewer columns mean your table can have more rows!).

Multi-functional docs

Problem: Some docs contain a lot of information that covers multiple teams, projects, or time frames. For example, we often see documents that act as a central project tracker for a whole department. This means that every detail about every project in the department is managed in a single table. But when you have larger departments with many projects happening at the same time, and lots of tasks assigned to each project, that table can get really big, really fast. Solution: Split up your doc. We caution makers agains housing too much in a single doc. Docs should be focused, limited to a single project, a single audience or a single time frame. In the scenario above, the department doc could be broken into team project trackers OR a tracker could be made for each project. This spreads out rows into multiple, smaller docs, reducing the risk of a single table/doc becoming too large. Learn more about what should have its own doc here.

3. Keeping row count in check

Establish a row life cycle

When designing docs, one should always consider how rows are created, how they modified over time, and, maybe most importantly, what happens to them when they are no longer useful. Most doc makers focus on the first two phases of a row’s life and tend to overlook the last. When a row reaches the end of its usefulness, you have two options for what to do with it: Delete it or archive it. Whichever mechanism you choose, you’ll want to identify the following:

When should a row be deleted/archived? Is it when it reached a certain status? After a certain amount of time?
How will a row be deleted/archived? Will it be a manual process or can you create an automation?
How often will rows be deleted/archived? Daily? Monthly? As soon as it meets the delete/archive criteria?

Keep docs focused

Docs that house lots of different content will naturally accumulate lots of rows. You may have a doc that contains a lot of data but that data isn't necessarily dependent on each other. It is a great idea in those cases to split up your doc into smaller docs focused on each individual use case. This can also help your team focus on work relevant to each use case. Learn more about what should have its own doc here.

4. Rolling out doc updates

While it is advantageous to address risky docs in the long term, altering a widely used document or process may cause disruptions to daily business operations if not managed properly. Check out this guide for tips on how to plan for a seamless and effective migration process.

Was this helpful?

YesNo