We’re running Coda as an operational application layer (relational data model, transactional button workflows, Packs, automations, multi-team concurrency). It’s been extremely powerful, but as row counts and active users have grown, performance is increasingly correlated with how much of the working set the client has to materialize and keep reactive.
In practice we’re seeing:
slower initial load as active datasets grow
UI latency tied to formula dependency depth and view complexity
action queues becoming more noticeable under concurrent writes
the need to tightly gate row exposure per view to maintain responsiveness
This all aligns with a model where a meaningful portion of the reactive data graph is maintained in the browser — which makes sense given the real-time, collaborative canvas.
My question is about long-term platform direction, not short-term optimization techniques:
Is there a roadmap toward more server-evaluated and query-on-demand patterns for large operational use cases?
For example, conceptually:
increased server-side formula execution for large datasets
view virtualization that doesn’t require materializing the full working set client-side
query-style access patterns for tables
server-executed transactional actions for high-concurrency workflows
I’m not looking for Coda to become a traditional CRUD app builder — the collaborative, composable doc experience is the differentiator. The question is whether the long-term architecture is intended to support this next scale tier of “doc-as-an-app” workloads.
If this is already an area of active investment (or if there are fundamental constraints in the current model), I’d really appreciate any perspective the team can share.
We’re highly motivated to keep this class of operational system on Coda if the platform direction supports it.
Docs on workspace level are work in progress. I expect a beta early summer 2026. These worskspace docs will support over milions of rows and I guess that is a server side approach.
I don’t have much to add that hasn’t been said in several corners of this community. However, I will add these observations:
The “Agentic” Escape Hatch (Advanced)
This is where your MCP and Automation capabilities shine. Instead of asking Coda to filter 50k rows:
External Query Pattern: Build a “Search” interface in Coda.
User types a query into a control.
A Coda Pack (or Webhook/n8n) sends that query to an external agent/DB.
The agent acts as the “Server-Side Query Engine” and returns only the 20 relevant rows to a display table.
Coda never sees the other 49,980 rows.
Offload Logic: Use the Coda External Security Pattern (@Doug_Loud’s method). It’s designed for security but excels at performance. Use n8n or an MCP agent to perform heavy calculations or aggregations externally and write just the result back to Coda.
For those who care, this short note from @Bill French deserves serious thought. Coda’s incredible power is amplified, when it becomes one of the core platforms within a workflow, such as n8n. You do not have to use one tool for everything and then wonder why it doesn’t work as planned.
As noted, in my earlier note there is the “external security pattern” that Bill was kind enough to mention. However, integrating n8n, Coda, and Qdrant (a vector database) has enabled reviewing Qdrant housed documents related to companies in the Coda database and displaying information from them easily on screen in Open WebUI. The users see no tables, no search bars that take them where they do not belong. And, yes, that information could then be put in an email or Slack and sent off.
It has been said that “if you’re a hammer, everything looks like a nail”. Don’t be a hammer, use your tool kit.
Hi @Brock_Eckles, great question! We are indeed investing in these use cases and the kind of architecture improvements you mention that enable a much great level of scale and performance.
That includes separating databases from docs, supporting up to a million rows of data, and improved patterns for what data is loaded and processed on the client vs server.
I’m excited to share more soon. We’ll have a community roundtable on this in a few weeks, and are planning a beta within the next few months. We’ve noted you down to reach out to when we’re ready to start a beta, as we’d love your feedback and to understand your use cases!
Pfff… a year later and we are still in the “coming months“ phase with maybe a “beta“, like… c’mon people, is the team coding backwards? Like… this is stand-up material. Single-page sharing is tough for 2-3 years in “we are investing“and that “investment” is never seen. I know I am condescending, but when you, as the product encourage me to put “everything“ in here as the “working layer of the future,“ but then you bark at me API limits, mobile app from the 1950s, or not able to use Coda in a Chromium browser like Edge… then I’m pissed as you aren’t even honest with yourself if the pricing is the issue.
Thank you for the response and insights, @Nathan_Penner. I recognize that you are in a difficult position and are offering support and visibility as much as possible. My hope is that my feedback below is received as a voice of a Coda-enthusiast that wants the platform to be successful.
With that said, I will echo some of the frustration that Cristian expresses in his post. There have been mixed messages on this specific topic and that has created quite a bit of frustration for folks. Personally, I cannot overstate the importance of this feature for my organization’s needs. Our datasets are growing all the time and Coda’s ability to function in a timely manner continuously erodes. I know there are work-arounds involving third party tools, but Coda’s simplicity is part of its magic.
The reality that I (and likely others) am facing is that Coda, in its current form, cannot support my long-term needs. I have maintained a strong [Enterprise] relationship with Coda for the past several years in two different organizations, but this is a point of inflection.
At this stage, I would strongly encourage the Coda team to commit to a specific date on the situation. The vague references to workshops and beta programs don’t mean much at this point.
I have to call you out with a quick fact check. I lived through the 1950s. I am that old. My phone didn’t run Coda. It still doesn’t. All that other stuff? Well, it’s kinda true.
