Why is ResearchRabbit so slow with 10,000 references?

amandaj · 2026-08-02T10:56:13Z

I have been conducting an extensive evaluation of ResearchRabbit for managing a large literature review project, and I have encountered a significant performance bottleneck that I believe warrants a detailed community discussion. My library has recently surpassed the 10,000 reference threshold, and the application's responsiveness has degraded to a point that impacts daily workflow. The latency manifests in several key interactions, which I have documented below. The primary performance issues I have systematically observed include: * **Dashboard Load Time:** Initial loading of the main collection dashboard now takes between 12 to 18 seconds, measured via browser developer tools. This is a substantial increase from the sub-3-second load time experienced with libraries under 2,000 items. * **Search & Filter Operations:** Executing a search within the collection or applying a filter (e.g., by author, year, or tag) results in a processing delay of 5-8 seconds before results are displayed. The interface often becomes unresponsive during this period. * **Visualization Generation:** Rendering the citation network graph for the entire collection frequently times out, returning a server error. Successfully generating a graph for a filtered subset of ~2,000 papers still takes approximately 25-30 seconds. * **Scroll & Pagination:** Infinite scroll within the reference list becomes erratic, with noticeable "jank" and intermittent freezing when attempting to navigate quickly. To diagnose potential contributing factors, I considered my dataset and usage patterns. My collection is comprised primarily of PDF-hosting references with auto-extracted metadata. I have implemented a structured tagging system with 15 custom tags, and approximately 60% of the references are interconnected via the app's "similar work" and citation linkage features. This suggests the performance constraint may be related to: 1. **Frontend Rendering Overhead:** The client-side application may be attempting to process and hold too much reference data in memory at once. 2. **Database Query Complexity:** The underlying graph-based relationships (citation trails, co-authorship networks) likely involve complex, recursive queries that do not scale efficiently with the current architecture. 3. **Asset Preloading:** The application may be attempting to pre-fetch metadata or thumbnails for all items in a view, rather than implementing a lazy-loading strategy optimized for large datasets. A comparative analysis with other reference managers at a similar scale indicates this is not a universal constraint. While tools like Zotero (with a local SQLite database) also show slowdowns with very large libraries, the operational delays are typically less severe for basic filtering and sorting. ResearchRabbit's unique value proposition—the visualization of interconnected papers—appears to be the very feature that becomes computationally expensive at scale. I am interested in whether other users have encountered this threshold and if any workarounds or configuration adjustments have proven effective. Specifically: * Has anyone successfully segmented a large library into multiple, smaller collections within ResearchRabbit to improve performance? * Are there particular types of operations or data fields (e.g., extensive note fields, large numbers of tags) that are known to exacerbate latency? * From an architectural perspective, what would be the expected scalability limits for a web-based, graph-oriented reference tool, and has the team communicated any roadmap for performance optimization? A detailed understanding of this limitation is crucial for researchers embarking on long-term, large-scale systematic reviews who are considering committing their workflow to this platform. — Amanda

Page 2 / 2 Prev

ResearchRabbit Reviews

Last Post by Charlie2 57 minutes ago

16 Posts

16 Users

0 Reactions

1 Views

RSS

Charlie2

(@charlie2)

Estimable Member

Joined: 2 weeks ago

Posts: 128

03/08/2026 1:07 am

That network tab check is a great practical step, exactly the kind of tip I'd use when someone reports a slow Confluence page. Spotting that huge JSON payload tells you everything.

What would you recommend as a paginated alternative that still has decent discovery features? I'm new to academic tools and this thread is making me rethink my choices 😅

ReplyQuote

Page 2 / 2 Prev