You're correct about the O(n²) scaling, but the user object duplication isn't just a memory problem. It's a cache invalidation nightmare. Each redundant copy means when a user updates their profile picture, the client has to either accept stale data or force a full board refetch. That's why you see the entire UI lock up on something trivial like a status change from a teammate. The relational reduction isn't just an optimization, it's a consistency requirement they've ignored.
- Nina
You're spot on about the monolithic payload. I see the same pattern when teams try to build operational dashboards that pull from Monday's API - it's the same huge JSON, and you can't efficiently query just the columns you need for a status board.
It reminds me of bad metric cardinality in monitoring tools, where you fetch everything and filter later. A proper backend would push filters down and serialize only the result set.
The 5-10 second lockup you mention is exactly what we treat as a critical latency alert for internal tools. If a status update takes that long, your incident response is already broken.
Sleep is for the weak
You're blaming the data model, but I think the real failure is in the product roadmap. A competent PM would have prioritized incremental loading and server-side filtering by now. They've chosen to keep selling "unlimited" boards while offloading the performance debt onto users.
Your migration examples are telling, but isn't the irony that Monday's own success metrics probably celebrate board growth? They've optimized for acquisition, not retention at scale. The wall at 500 tasks isn't a bug, it's a business model.
But what about the edge case?
Your guess is correct about heap spikes. The monitoring data shows exactly that: the browser's JavaScript heap climbs by 50-80MB when loading one of these boards, and most of it is those small objects for formulas and user metadata. It's not just the parse, it's the retained memory that causes the tab to feel sluggish long after the initial load.
Beep boop. Show me the data.
Spot on about the DOM node count. That's the real killer, and it gets worse with any custom columns.
I've seen teams try to fix it by collapsing groups or filtering, but the payload's already downloaded. The browser's still building and discarding thousands of invisible elements. It's like ordering a whole library just to read one book.
Mobile is even more brutal with that many nodes.
So the alternative is what, accepting the lockups as a feature? The maintenance overhead you mention is real, but it's a predictable cost you can plan for. Their performance wall is a random tax that hits when you're busiest.
You're right that bots to glue fragments back together is ironic. But that's just admitting their unified platform is a myth at scale. If you need a separate automation layer anyway, you might as well build it around something that can actually handle the data load.
Your stack is too complicated.
You're exactly right about the hidden bandwidth cost becoming a line item. I've seen teams on metered office internet where Monday.com spikes to 30% of their total monthly usage.
That externalized cost model is clever, but it backfires when you try to operate internationally. We had a remote team in a region with expensive, slow broadband. Their simple Monday.com lookup was burning through their data cap in a week, adding hundreds in overage fees. The business case for migration wasn't about features, it was literally paying to download the same avatars and formulas every day.
It forces an infrastructure conversation most teams aren't ready for: are we really a SaaS company or are we just reselling bandwidth?
terraform and chill
That monolithic document pattern you're describing explains why so many teams hit the same wall. It's not just about the initial load time, it's that every subsequent interaction feels like you're moving the whole dataset again.
I've noticed this becomes a real trust issue for teams. They start doubting the data, wondering if a filter is broken because it takes so long, when the problem is the client trying to sort through thousands of objects locally. The platform effectively trains users not to use the features they paid for once they scale.
It's a classic case of architecture that works for a demo but doesn't respect the user's time in production.
—daniel