What are Codas current limitations and how can we work with them?

1

I am just getting started with coda and trying to learn how to do all the things. I quickly became very hyped for the seemingly endless possibilities of the system.
I envisioned how I would create a digital version of my company with tasks, financial & sales data, projects, goals, etc. with coda and started working. All the while I was never having a thought about coda’s potential limitations. Today I came across a community thread from 2020 talking about potential limitations in document / table sizes (Why would you NOT try to manage all a Tech Start-Up's stuff in Coda? - #22 by Bill_French)

This topic brought up a couple of questions for me:
Is there a place with “best practices” regarding doc design, that take these limitations into consideration? What do these limitations look like today? What are the most common pitfalls? How could I best ensure the long term performance of my projects?

2 Likes
2

Hi Kevin,

Unfortunately your questions is a little bit like “How long is a piece of string?” It depends.

And it depends on a whole bunch of things: How large is your company; What kind of financial and sales data you want to store?

I would definitely not recommend to run the financials of a large company in Coda, and why would you? There are plenty cheap and even free accounting packages.

You will start to notice lags from a few thousand rows up in a table, depending on the kind of columns in the table and the calculations, if any. I have had a list of GL accounts totalling 4000-5000 rows. It worked, but was slow. A few seconds response time in working in that table. (The rest of the doc was not affected by it).

The thread that you referenced is a good source of information. The general discussion is valid, but the specific limitations, 2000-3000 rows and collapse is no longer applicable. In the 15-18 months I have been on the forums, I have not heard anything like that once. There has also been several upgrades geared specifically towards improving performance, and more recently the implementation of Coda 3.0 which was a major overhaul of the product.

The functionality of Coda is really in a class of its own though. There are other packages similar (Notion) or more or less similar (AirBase, Fibery). But none of them has the ease of use and feature set that Coda has.

To me that makes up for limits in size, which I have not really bumped against yet. There are many ways to address hat in your design though - annual tables for date dependent data, archiving for data with a short shelf life, etc etc.

I would like you to try a few things in Coda, ask specific questions in the forums, and get to know the product. I am very certain that you will lots if good in the product. One of the major new developments is the ability to create user developed pack. This is extending Coda functionality by leaps and bounds, and nobody knows what the future holds.

Finally, I do not think that any one tool is going to satisfy all needs. But I am doing a lot of things in Coda now, that I, as an accountant, thought I would never do in Coda and keep in spreadsheets. But it took my a year to get the Excel patterns out of my head, and really understand what Coda can do.

It is not a trivial tool.

Enjoy
Rambling Pete

11 Likes
3

If this is your idea of rambling, sign me up for many chapters! Excellent guidance - precisely my thoughts when I read this inquiry.

The only thing I would add has nothing to do with Coda and everything to do with recognizing the importance of identifying operational data and process requirements in contrast with strategic data requirements. Carving out a deep understanding of data at rest and how you plan to deal with it in the context of business analytics is as important as attention to operational data flows.

3 Likes
4

Thanks Bill.

I am going to ponder this. I am a big proponent of “systems thinking” (NOT computer systems.). Your comment makes me explicitly wonder how data changes, and how it does not change during process flows.

Rambling Pete

2 Likes
5

Same here. But the moment I drift into a systems thinking approach, I tend to lose the audience who are largely domain experts and power users that just want to create a vastly #no-code solution with some degree of immediate gratification. This is the promise of all democratized IT offerings, eh?

I’m trying to not over-think my advice to those wondering if Coda is a good fit and with that, I’ve noticed that if you can inspire newcomers to think about their information in two distinct lanes - operational and strategic - they will have a better chance and expectations will be a little better managed.

Imagine a simple thought process with a big T on a whiteboard listing the things you need to do daily with your data on the left and the things you need to do monthly on the right. Just framing your information narrative like this will help power users establish requirements that are considerate of each side of the T chart.

3 Likes
6

Thank you very much for your replies. Do I understand correctly, that the major constraint with coda would be the size of tables, since that will negatively impact performance?

Are you saying coda tables would be the place to store operational data with “historic” information being archived to another database of sorts and strategic information should be stored in another place?

I drew this up in order to visualize the idea that I currently have:

image
image1266×638 57.1 KB

This would ensure that tables in coda could stay relatively small and we can at the same time draw insights from bigger information pools while staying in coda.

Another question that came up in this process would be:
In order to download data from the third party information silos. Would it be more convenient and potentially cheaper to do so in coda (maybe a dedicated doc for handling each source of information) and then push historic data (more frequently for higher density information) to a relational database?

For the general architecture in coda I would be using separate docs for different functionalities and using sync tables to cross reference information.

2 Likes
7

The biggest question is, how much data are you talking about?

As bill says - how much strategic data, how much transactional data? The devil is on the details.

Before you commit to more than high-level ideas for such a big project, I would strongly encourage you to get thoroughly acquainted with Coda functionality. What are the practical points to create a new doc, what are the practical points to create new tables, etc. Coda is not a relational database, and over and over I see people make the mistake of rushing in, and treating Coda like the tools they are used to" be it relational databases, Notion, Excel, airbase or whatever.

Regards
Piet

1 Like
8

We are a small company only getting started. At the moment we are two. Hard to say how many people we will scale up to. Lets be overly optimistic and say 20.

  1. so tasks & OKRs for 20 people. If we assume 20 Tasks per user per week that would be 1600 tasks per month. if we want to keep them for a month after finishing that’s 3200. With 400 in a pool of potential tasks for the future that’s a table with 3600 rows.
  2. OKRs would be max 5 per person + 5 for the company and maybe 5 per department. That should not be an issue.
  3. products. we would store information for things like “dimensions”, “sourcing prices”, “manufacturing information”, “manufacturer contact info”, etc.
    Even if we end up with 60 products that should be manageable within coda?
  4. Projects & Processes. I will assume that we are running no more than around 10 projects at the same time, which would be a lot and even then I don’t think these would generate large amounts of data.
    All of these things we are handling in Google Sheet at the moment.

then for the strategic data:

  1. sale info. Let’s assume we sell each product 400 times each month. that would be 24k entries a month. Around 6k a week and around 860 per day. This is information I would hold in a relational database. I would pull this data daily from it’s source through coda and then push it to the database / pull it straight to the database.
  2. financial information & marketing performance. I would handle this information similar to sales info as it will be just as much or more.
    This info could be stored and handled completely on the side of the relational database with no touching point to coda.
    Coda would, in this scenario, only come in and request (aggregated) information in order to display it in coda so we can make informed decisions.

What would you say is in your view the difference between these and coda? And what would be the core functionality / use case for coda?

3 Likes
9

Hi Kevin,

i do not see any problem with the data volumes that you are mentioning. Hopefully somebody with better experience with Coda performance will chime in as well. But what your are describing is well within the limits.

Differences to:
Relational databases: Coda is not going to enforce relational integrity, it is not ACID, it does not have a formalised query language and functionality. It only uses a single column as a key. (You could get around that by creating a concatenated column of the fields you need.)
Notion: It has been more than a year since I settled on Coda rather than Notion. One of the big problems I had with Notion was its lack of boolean functionality in searches. As fas as I know the pack functionality is unique to Coda. It did and does still not exist in Notion, or in any other tools as far as I am aware. That is a huge advantage that Coda has. The Coda canvas column addresses the same idea that Notion has with it built in pages for each row. But the two implementations are quite different.
Excel: Coda has a combination of Word and Excel’s list processing functionality. The functionality is well integrated, and yes, each individual MS product has much more functionality. But add buttons, a formula language and packs, and you have an emergent product that is way much more than just a combination of Excel and Word functionality.

Packs allow one to extend Coda - new formulas, as I understand even new table columns, and bespoke integration to basically any other software package. This is on top of the existing Zapier integration.
Airbase - I must admit, I gave up on Airbase fairly quickly when I could not find a Word kind of functionality as part of it.

Core functionality of Coda? I think that is a bit like asking whether Excel’s core is engineerinh=g, accounting or anything else.

I have used Code to build a website:

I am busy building a tool to use to document (smaller) SAP implementations:
This will cover meetings, system design documentation as well as configuration requirements. (And some smaller master data sets as well.

@Paul_Danyliuk has built a very nice pizza ordering front-end:

And back to me - My version of a Coda todo list. (This is actually a subset of the meeting functionality in the SAP KAT documentation above.

As you can see, vastly different documents/ Apps,

Reagrds
Piet

6 Likes
10

@Piet_Strydom Thank you very much for your time Piet. Your remarks were quite helpful.

3 Likes
11

HI Kevin,

It is a pleasure. It also forces me to clarify my ideas.

Just on your “third party information silos” - That is where Zapier and integration packs would come in. Ido not know what accounting software you are using, but I know there has been people doing some work on integrating with Quickbooks, and there is a pack to integrate with online banking. It might be still in beta, not certan.

Regards
Piet

4 Likes
12

What a wonderfully insightful discussion - I’d like to recommend the three of you for “poster example on how to conduct a respectful and interesting community discussion” (this might sound sarcastic written down, but please know that I intent this with nothing but sincere appreciation).

Agreed, @Leandro_Zubrezki is creating a Quickbooks pack to integrate Quickbooks with Coda.

As to your concerns regarding table size, @Kevin_Donath, the prolific Coda-builder @Connor_McCormick1 is working on an Archive-pack allowing one to use a third-party service as an external storage. He’s currently looking for beta-testers: Archive Pack Beta Testers!

These are the two community developments that came to mind when reading this read, will add more if more come up for me.

All the best from Austria,
Nina

6 Likes
13

some experiences we have had at agile-dynamics regarding coda limitations…

we now have a few documents with more than 10k rows.
and they function well.

as these docs increase in size, we are planning ways to manage performance issues before they arise.

the 3 big improvements to performance so far have been…

  1. archiving detailed rows to archival documents but retaining monthly summary rows so our long-term dashboards work. once a project/claim/account reaches its end-state, it is sent to the appropriate archive doc by crossdoc. a user then confirms the archival was successful and those rows are deleted via a button action. probably could be 100% automated, but we are being cautious.

  2. replacement (where possible) of regular column formulas with once-off calculations that occur when new rows are created (using the column options → value for new row). this is tricky and needs careful analysis. if the values dont ever change during the rows life-cycle, then that is fine. but if these values do need to change, we must either do so via a button/automation (next option) or leave it as a column formula.

  3. replacement of the most expensive column formulas with computations inside buttons, so we control when they occur. this is helped by the fact that we have an EDIT button on most rows that brings the user to a specific dialog modal (in fullscreen view mode) to edit the rows details and we have a DONE button in each modal to bring the user out of the dialog. we can attatch those computations to the DONE button.

however, you need to guard against situations where users might ‘escape’ from a dialog without using the DONE button. they might change values on the row, but not run the computations in the DONE button.

so we set a timestamp on the row when the DONE button is pressed. and a warning formula column compares that timestamp to the ‘last modified’ value for the row, and flags it with an error message if they dont match. so we at least know when this has happened, even if we can’t prevent users ‘escaping’.

btw. the other thing we need to detect is when rows are deleted. we provide a DELETE button in some cases, which flags rows as “logically deleted” and handle the logical deletion of dependent child rows in other tables. this process opens a “confirm deletion” dialog so users must press a second DELETE button. logical deletion can be undone, actual deletion cannot. these DELETE buttons adjust calculated values accordingly across the database.

to detect the rare cases where the user ACTUALLY deletes a row (selects the row & presses the delete key or selects the delete option) we keep 2 counts per table on a hidden page. the first is a formula; table.count() and the second is a number that we increment when we create a new row and decrement when a row is officially removed by the appropriate action.

if those counts dont match, then someone has deleted a row manually and an error message is displayed on the top of every page.

of course, we wouldnt need that trick if we could lock pages so as to prevent row deletions, but that option dont exist alas. we do use the option to prevent users adding rows ad-hoc.

max

10 Likes
14

Thanks @Nina_Ledid for the mention! The Pack is up and running → QuickBooks Pack, extend Coda with QuickBooks - Coda

BTW what an amazing discussion!

3 Likes
15

Kevin,

This confuses me, but I’m sure you have a keen idea what the process should be. My observations could be a little wonky, but here it goes.

  • If the sales transactions are being managed external to Coda, I assume you needn’t replicate the transactions in their entirety in Coda to gain an effective visualization of daily sales activity or even establish a daily log of sales or other aggregations.
  • We often believe that transactional data needs to be represented in discrete rows. Imagine a case where dozens of customer touch points occur but a single record is able to store them as structured JSON data objects. I’ve done this in Airtable and Coda with optimizing results.
2 Likes
16

@Xyzor_Max Max those practices for data integrity and protecting the doc from “escaping” users are amazing! Thanks for sharing them!

I’ve implemented a similar solution to your “DONE” button (without the computing inside of it) to lead the way for users to close records and it works like a charm. Users really find it way more intuitive than just clicking outside of the modal chart.

The idea to have alerts checking if the workflow was correctly used to ensure data updating are genius! Got plenty of inspiration from this and will use those ideas.

From my work with non-tech-savvy users I’ve always focused on finding ways to turn Coda more into an “app experience” so users have defined workflows and it’s challenging but this type of ideas help a lot.

Thanks for explaining them in such detail!

Greetings from Colombia :colombia:!

1 Like
17

well, here is a NEW trick that closes a dialog and returns the user to wherever they were when the dialog was opened.

User().ObjectLink().OpenWindow()

without the need of my complex RETURN values or stack.

thank you @Adam_Clewley for this discovery

it works GREAT!

max

8 Likes
18

Isn’t it User().ObjectLink().OpenWindow() ?

3 Likes
19

@Breno_Nunes Yes, in my testing it needs OpenWindow() to work properly. And to make it even easier to use, you can put a named formula with this code in a settings page and call your named formula without ever having to worry about the correct syntax again.

4 Likes
20

Hm… playing with this tonight.

If you open a modal from a model, then this doesn’t seem to work, although I cannot work out why. It just spits me back onto the last open non-modal page.
I’m currently looking at a very modal heavy UX and desperately trying to get this to work.
Any other pointers?

I’m using
User().ObjectLink().OpenWindow()