All resourcesGuidesCoursesTips

10 min read

Managing large row counts

How to identify and address Superhuman Docs with high table counts.

Having too many tables in your Superhuman doc can lead to various challenges and risks. In this guide, we explore the reasons why having an excessive number of tables can be problematic and provide solutions to help you manage and optimize your doc effectively
What you'll learn:
  • How to determine table count
  • Risks of having too many tables
  • Tips for reducing table count
  • Scalable doc schemas
buttons
What you'll use:
  • Tables
  • Views
  • Database basics

Checking table count

Use the doc map to see a list and count of all the tables in your doc. Table count is listed at the very top. Remember, there are 2 types of tables in Superhuman Docs: independent tables and connected views. This guide focuses on what to do if you have a large number of independent tables. You can learn more about tables versus views here.

Risks of having too many tables

 There are 3 main reasons having too many tables in a doc is risky.

Data connectivity

 When you have data spread across independent tables, it’s not connected in the same way as it would be in connected views. Let’s explore an example: A “meeting notes” doc where a brand new “action items” table is generated for every single team meeting. Because these are independent tables and not views of a central “all action items” table, the team is not able to:
  • Compare entries across all meetings.
  • Easily calculate how many total action items have ever been created.
  • Pull a list of all incomplete action items across all meetings.
  • See a personalized list of all of their assigned action items across all meetings.
If you have multiple independent tables with similar or duplicate data, you’re not fully utilizing the potential of Superhuman Docs. However, if you turn these tables into connected views of one main table, you can do so much more with your data.

Usability

 Let's be honest, who likes clutter? If you have 50+ tables that are all unique and therefore could not be consolidated into views, this may be a sign that you have too much going on in one doc. Docs that house many different topics or workflows can become difficult to use and navigate, and finding specific information within the doc becomes challenging. It is often the case in larger docs that not every section is relevant to every user. This means users are spending more time sifting through irrelevant content, searching for the right page, and the right table, to find what they need. This can lead to inefficiency and frustration for your users. Not sure what should stay and what should go? Learn more about what should get its own doc here.

Performance

 Doc performance is all about doc size. Doc size is calculated by adding up the sizes of all doc elements (pages, tables, views, rows, buttons, etc). In docs with large table counts, it's often not the tables themselves that cause issues — it's the number of rows. If you have 100 tables with 100 rows each, that is the same as having 1 table with 10,000 rows! It’s easy to see how quickly things can add up and eventually, your doc will slow down. To check your doc's current size and stats, click the three-dot menu in the upper right corner of your doc, select Doc settings, and then Statistics. This panel shows a breakdown of your rows, pages, tables and views, buttons, and formulas so you can quickly identify what's contributing to doc size.
Learn more about doc size and performance here.

Reducing table count

 If you have a doc with too many tables, it’s likely for one of two reasons. 1. You created tables when you should have created views 2. You have an unfocused “mega doc”

Scenario 1: Tables that should be views

 When discussing tables, it’s helpful to think of your data in terms of nouns and adjectives:
  • Rows = nouns
  • Columns = adjectives
For example, if you want to create a table to track your tasks, the task itself would be the noun, and each row would represent one task. The columns would hold descriptive data about the task, like the status, owner, or due date. Take a look at your tables and consider: Do any of these tables share a common noun?

Solution: Combine tables into views.

This doc schema is called “One big table”. Here, you create one table for each “noun”, or type of information, and then make filtered views of that parent table for all your individual needs. Because all your views are connected to the same main table, you unlock the ability to run calculations on all the rows, change how you slice things up down the road, and rest easy knowing that if an entry is visible in multiple views, you only need to change it in one view, and all the others will automatically update. If you’ve identified tables in your doc that would be better as connected views, follow this guide for instructions on making the transition. Check out this guide to learn more about this doc schema.

Scenario 2: The unfocused “mega-doc”

 If you have a ton of tables that are truly independent of each other and would not work as views, it's possible you may have a mega-doc on your hands. A "mega-doc" is a comprehensive doc that serves as a central repository for various topics, often spanning multiple teams or departments. A company-wide wiki is a common example. Each department has its dedicated section with all of the information running the entire company organized in a single doc. Similarly, project docs can also adopt the mega-doc setup, containing all the relevant information about every project a department is working on. As content volume grows, mega-docs will not only become hard for users to navigate, but they will eventually hit doc size constraints. In general, it's better to have fewer things in your docs rather than more. This way, users don't have to dig through pages that aren't relevant to them, and your docs can be more focused on specific audiences and situations. Learn more about how to keep docs focused here.

Solution: Separate data into more focused docs

Typically, docs are created with a specific use case and audience in mind. If different parts of your doc are meant for completely different audiences (for reasons like UX or privacy), it might be a good idea to separate them. If you find yourself constantly making pages that will only be used by a small group of users, it might be worth creating a new doc for them. Check out this guide to learn more about deciding what content goes in what doc. How you slice things up depends on the content of your big doc. Popular options include:
  • Team-based - Do your big docs have separate team pages or spaces for several different teams? Consider making each of those spaces its own team doc.
  • Topic-based - Does your large doc house information on multiple different projects or subjects? Consider making a separate doc for each.
  • Time-based - Create a new doc for specific time periods, like a new OKR doc for each quarter.
Once you’ve decided how you’ll split things up, use “Copy page to doc” to copy the content into a new doc. Double-check that the content was correctly copied, then delete the pages in the original doc.

Rolling out doc updates

 While it is advantageous to address risky docs in the long term, altering a widely used doc or process may cause disruptions to daily business operations if not managed properly. If you do decide to make significant alterations to a business-critical doc, check out this guide for tips on how to plan for a seamless and effective migration process.

Now what?

 A well-structured doc is easier to maintain, faster to navigate, and more useful for your whole team. Here are a few good next steps:

Was this helpful?

YesNo