We're considering upgrading our 12-person R&D team to ResearchRabbit Pro primarily for the collaborative features—shared collections, real-time updates, and permission management. However, I'm skeptical about how these features perform under actual load with a team our size, as most reviews focus on individual or very small group use.
Has anyone conducted a real-world stress test on the Pro plan's collaboration? I'm specifically concerned about:
* **Update Latency:** When multiple users add papers to a shared collection, what's the propagation delay before others see them? Is it truly real-time or a periodic sync?
* **Concurrency Handling:** What happens when two members edit the same collection's metadata simultaneously? Is there a clear conflict resolution log?
* **Notification Spam:** With a dozen active researchers, does the notification system become a bottleneck, or can it be finely tuned?
Our workflow involves high-volume paper discovery during sprint-based literature reviews. A failed sync or a merge conflict would directly impact our project timelines. I'm looking for performance benchmarks, not just feature lists. If you've measured these interactions or have experienced scaling issues, please share your data or observations.
sub-10ms or bust
> "I'm looking for performance benchmarks, not just feature lists."
You're asking about latency and conflict resolution, but the real question is whether 12 seats on Pro is even worth the burn rate. I've seen teams blow thousands on these plans only to find the sync is basically "pull to refresh" under load. ResearchRabbit hasn't published any concurrency benchmarks because they don't have them. Their docs are vague about conflict resolution - last writer wins, no log.
For a 12-person sprint with high-volume paper discovery, you're better off with a shared Zotero group and a lightweight webhook to notify. Costs zero extra, and you can actually instrument the sync lag yourself. If you must use ResearchRabbit, test it with 3 people first. I bet you'll see 5-10 second delays once the collection hits 200+ papers.
What's your per-seat budget? That might change the calculus faster than any latency metric.
show me the bill
You're right to be skeptical. The "real-time" sync is optimistic polling, not push. We tested it with 8 users adding 5 papers each in a 30-second burst - latency varied from 3 to 17 seconds. It's not deterministic.
For conflict resolution, it's worse. There's no log. If two people edit the same paper's tags, the last HTTP PATCH wins silently. You won't know whose data was clobbered.
Notification tuning is primitive. You can't scope alerts to collection subgroups, so a busy shared collection floods everyone.
If sprint timelines matter, this isn't a production-grade system. It's a note-taking app with a shared folder bolt-on.
-- bb
Your test results align with my team's experience. The 3-17 second latency window you measured is consistent, but we observed it widens under sustained load. After an hour of continuous use by 6 people, we saw spikes to 45 seconds, which points to a queue backlog issue, not just network delay.
The lack of a conflict log is the deal-breaker for any coordinated work. You can't run a postmortem without data. It's a basic feature in any collaborative system that handles state.
Their notification system is a broadcast channel. It fails the on-call principle of actionable alerts.
Five nines? Prove it.