I’ve hooked up my Docs to several other services via zapier. I just got an error from Zapier saying that the API is limited to docs with 1,000 rows. Is anyone else seeing this? This limitation makes Coda useless for any business function. Any ideas or workarounds to get around this? Coda keeps adding new Packs that encourage connectivity yet this change renders hundreds of hours of work useless.
2 Likes
What is even stranger is that their published documentation says that they support docs up to 50,000 rows or the ‘Encyclopedia Brittanica’: https://help.coda.io/en/articles/3370370
Hi @Johg_Ananda,
I can understand your frustration with wanting higher API limits and for Coda to handle more data in general, but I also wanted to offer some perspective and a little bit of an explanation of why some things aren’t infinitely scalable.
To offer a ballpark figure, viewed from a resource usage perspective, your docs generally fall in the top 0.0001%. You’re in the top very few implementations that push a Coda doc this hard. I’m positive there are other use-cases out there that would benefit from high limits, but in general, our target audience is far from this type of use. Coda is a fit for a lot, but not absolutely everything.
When it comes to offering the features and UI/UX that we do, this isn’t conducive to working hand in hand with high performance and massive datasets out of the box. These two aspects sit at opposing ends of a spectrum maximizing both takes quite a bit of work.
In building out a product, these will each take the front seat at different times, they will leap-frog each other as we improve the product.
I’m very happy that you’re using Coda and that you enjoy a lot of the features, but I’d really suggest you don’t force certain use-cases if you’re near maxing out what can be done.
@BenLee This post references a 1,000 row API limit. That is in the top .0001% of useage?
2 Likes
No, that number in particular is not. That might also be an effect of always using more than what the system can allot so there may be a need to throttle a particular user at some point.
Hey @BenLee - this is all interesting and good information!
When designing docs, what should we consider in terms of amounts of data in a table (or a doc)
It doesn’t take much to build up large data-sets when running even a small business.
If we here have 6 bookings a day, thats 1500 bookings a year.
Perhaps there is a way to build out an auto-archive feature so one can set a table to archive data that is older than x number of days (or a date column ). I’m thinking of building one for our tasks - which can easily be 30+ per day.
But having the API is the reason many folk are here (from notion) and knowing the parameters in which it will work is key. Clarity on this would be great! 
2 Likes
The bottom line is being efficient in what you’re trying to do. If you have a doc with 1,000 rows and it’s running some type of formula on all 1,000 rows with every data update and every API call is causing it to traverse through all 1,000 rows every time, you’ll run into issues. For the most part, we don’t see docs hitting these levels. We have docs that our entire team uses everyday with 10,000 rows and they run just fine with multiple people in them regularly.
2 Likes
Thanks! Appreciate this.
@BenLee thanks for adding more light to this. Me thinks anyone who’s posting on these performance threads is trying to be efficient in what they’re doing. You have the curse of knowledge, knowing what ‘being efficient in what you’re trying to do’ means in Coda. It stil feels opaque, although the performance tool has helped. Could you elaborate on:
Could you give some examples of which formulas create this effect and which ones don’t? Best practices on how to work around this limit?
1 Like
Here’s a great help article on optimizing formulas…
I will say to make sure you use the right tools for each job. Coda might not always be it, but when it is, also try to accentuate Coda’s strengths. An example would be some of our announcement emails. We actually use a template I made for creating and sending an HTML email for our newsletter. But we have hundreds of thousands of people that might be subscribed, so we generate the code for the email with the template, then use a different service for actually sending it.
1 Like