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

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.


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


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.


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:

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.


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.


1 Like

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?


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,



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


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.



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,


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.



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

BTW what an amazing discussion!



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.

@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

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


without the need of my complex RETURN values or stack.

thank you @Adam_Clewley for this discovery

it works GREAT!



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


@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.


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

You are correct, that is nog going to work. Because you don’t have an objectlink of the modal, just the originating page. And there is currently not a way to ‘stack’ multiple object (modal or otherwise) to trace you back the same path you came from.

Or to say it differently: this ‘trick’ only works properly one level down the line.

And to be honest, I can’t think of an easy way for Coda to implement this.

Hm - cool… good to know. There’s the back button - which is great (and therefore MUST have the code running in the background that we would need, but this isn’t exposed to us it seems.

For the moment there doesn’t seem any way to create “save and close” and “revert and close” systems. I can only get the user to hit “save” and then the back button, and the “revert” and then the back button. Not ideal. This is cool of course for users who use the systems over a long time, but not for freelancers / new staff. And one of the big reasons for going with coda for PM is risk management for our small business - getting as much info onto a page as possible.

I’ll keep thinking of ways around it. But likely not the way I was planning.