10 min read
Coda at scale: Managing row count
Explore the considerations and challenges associated with large Coda tables.
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.
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.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