Is there a functional limit to table size in Coda?
I created a new document and started by dumping in a 25,000 row x 30 column Excel spreadsheet into a new table, and then added some other tables for lookup purposes. Now any actions filter, formula, sorting edits that I make freeze the document in Chrome for as long as 5+ minutes.
Performance is very good on the smaller Coda documents I created. I am working on a Quad Core i7 MacbookPro with 16GB RAM.
See here
Your observation is similar to mine. The performance issue is related to the Coda servers, not to your local workstation.
I am really interested in a response for one of the Codans. This is not an idle question, but something that I want to understand if this performance will be improved.
Hey all, we’re taking performance issues very seriously here, especially as more users such as yourselves have started pushing Coda in amazing ways to do more and more with more and more data.
We’ve always had people working on speed but we now have a dedicated team. Our focus right now is really understand what most impacts performance and also what you all care about most.
So if you have docs that have speed issues we’d love to get on a call with you to understand where your issues are. In the short term sometimes we can optimize your doc a little more, but obviously in the long term we want to make Coda as fast as possible in all situations.
Do keep all your feedback coming!
Hi Glenn_Jaume
I have raised this issue for over 6 months now.
As a first pass, it is straightforward- when a table exceeds about 5,000 records it slows down considerably, Above about 10,000 records it is almost unusuable to even load the document, no less to do searching.
If you would like to arrange a call i would be glad to do so. I have basically come to the conclusion that your intent is to use Coda as a “database lite” and to integrate by embedding a traditional database for more serious database needs. If I am wrong and you get to the point where you feel performance is acceptable for databases into 10,000+ rows, let me know and I will be more than glad to try that out.
Thanks.
Our ambition is certainly to let you have very large data sets like that, I’ll DM you about setting up a call as it would be great to see one of your larger docs and talk about what you would see as the priorities.
I had a similar question. Al’s suggestion was “create views, not tables.”
Hi. I echo the previous comments about no of records. More than a few hundred and things become really slow in my financial and todo apps. In the budgetting app I load transactions from my bank. Originally I tried to delete all records and reload. This crashed but I found that using cut n paste to overwrite rather than deleting made a huge difference.
Happy to share examples or provide additional info.
Regards
Simon
Dear @Glenn_Jaume and @mallika
More and more users start to have negative experiences when creating bigger projects!
To be honest me too, unfortunattely I have to use Airtable for bigger projects.
As you can see, I am an active user of Coda and this community and we would really appriciate some more clarity when we can expect Coda to tackle this subject. Obviously it’s a 
As always, thanks following up this subject.
//JP
Hi @Glenn_Jaume,
We have built a document for serve some purposes of CMS and ERP, however it really is pretty slow so we basically are on hold until performance improves. Do you think we can have a session to try and figure at least some improvements so we can start using it?
Unfortunately, I’ve run into the performance limitation and it makes my app unusable. It’s a shame because it’s pretty much ready to go otherwise.
Here’s an example…
The yellow boxes cover up names to “protect the innocent” but basically what we’re seeing is a table of hours that each engineer is expecting to work on each of their projects in a particular week. The number in the cell is number of hours for that particular project but the colour of the cell is determined by the number of hours that engineer is working across all their projects in that week. If he or she is expecting to work fewer than 20h in total across all projects then the cell is orange. If they’re working between 20 and 40 hours it’s green, and if they’re working more than 40h it turns red to show that he or she is overloaded.
So, when I’m scheduling this particular engineer on project 18110F during week-ending May 5th, I’m only asking for one day (8h) but the cell has gone red so I know that they’re working too many hours on other projects for a different project manager (the whole table is filtered by project manager).
The table is data-enterable, so as I update the hours I want to see the cell change colour as a visual indication that the schedule is feasible.
And it works perfectly! It just takes a whole minute for the colour change to take place. 
That’s not usable.
You can then go and look at the engineer to see what else they’re doing:
This table is also data-enterable so you can approach the scheduling problem from multiple angles. As soon as the total number of hours in that week falls below 40 the whole column goes green.
Some stats:
Number of engineers: 53
Number of projects: 247
Number of weeks: 12
Number of rows in engineer-project-week join table: 1848 (engineers only work on a handful of projects)
Number of rows in engineer-week join table: 624 (some rows look to be missing here)
The largest table is <2000 rows so it shouldn’t really take a whole minute to add up 7 numbers and change some colours.
Let me end by saying that it’s literally taken me just a couple of days to build all this from scratch which I think is a massive tick for Coda - it’s been really easy to set up and a lot of fun! I just need the performance to improve.
P.S. I also have code to calculate revenue per project as well as plan vs. actual on a quarter and yearly basis. It’s so easy!
Hi @Simon_Layhe thanks for the feedback and I’m sorry for the slow response. I’m taking over for Glenn and working on improving the performance of Coda docs.
I’m surprised to hear that things are running slow for you with just a few hundred rows, since we don’t usually see issues with docs of that size. I would love to take a look at your doc, can you please share it with support@coda.io. Also can you share some examples of actions in that doc that feel slow?
We have tools that can help us analyze the performance of docs so I can let you know if a certain formula is slowing things down. Moreover, seeing what performance issues users are facing most often is super helpful in prioritizing our efforts.
@Jean_Pierre_Traets thanks for the feedback and I’m sorry for the slow response. I’m taking over for Glenn and working on improving the performance of Coda docs.
We have tools that can help us analyze the performance of docs so I can let you know if a certain formula is slowing things down. Moreover, seeing what performance issues users are facing most often is super helpful in prioritizing our efforts.
I would love to take a look at your doc, can you please share it with support@coda.io. Also can you share some examples of actions in that doc that feel slow?
@Nick_Milner thanks for sharing the details. Is it possible for you to share that doc with support@coda.io? We have tools that can help us analyze the performance of docs so I can let you know if a certain formula is slowing things down.
If not, I’d be happy to jump on a video call to go through this with you and see if we can get to the bottom of this.
Hi @Angad, I sent a sanitised version of the doc to support on April 9th with the subject line: Coda Performance Issue (from Nick_Milner)
Thanks again.
For anyone else following along, Nick was able to speed up his doc significantly by making a change to one of the formulas. More on that here: Realistic number of rows in a table
Maybe this is naive. I use Onshape every day. It’s cloud CAD in the browser. Their networking solution might be interesting to some of you, from a performance perspective. After all, Onshape CAD models are essentially large tables updating live in the browser. Very Coda-like! Only, instead of rendering the entire model at every step, “every change is recorded as an increment.” I wonder if Coda could benefit from this philosophy?
Here’s a link for those of who want to dive deeper: https://www.onshape.com/cad-blog/under-the-hood-how-does-onshape-really-work
Thanks Jack, will pass this on to the team.
For everyone following along, we just made some announcements related to performance:
It’s also slow and clunky just to scroll through a pretty big table - I have 140 rows (mostly text / pretty simple) and just scrolling down to the bottom of the table is painful
