Scaling notebooks to hundreds or thousands of sources

[nguyenloki258]

Hi! Thanks for the great project.

I have a quick question regarding notebook capacity.

Is there a limit to the number of documents (sources) that can be added to a single notebook? If so:

• What is the maximum number of documents per notebook?
• Is this limit configurable?
• Are there any practical performance recommendations when working with a large number of documents?

I couldn't find this information in the documentation, so I wanted to ask here.

Thanks!

[Jgmro]

Hi, here's what I found from the project docs and previous discussions:

Hard limit: there was an artificial cap of 50 sources per notebook in the code, reported in #299. The maintainer (@lfnovo) fixed it and the fix has been rolling out in subsequent releases, on recent versions there shouldn't be a hard cap anymore. Worth confirming which version you're on.

Practical recommendation: the official FAQ suggests 20–100 sources per notebook for best performance (docs/6-TROUBLESHOOTING/faq.md).

If you're on an older version and still seeing the 50-source ceiling, updating to the latest release should unblock you otherwise, staying within the 20–100 range per notebook is the recommended sweet spot.

[nguyenloki258]

Thanks for the clarification!
I have one more question: even though there's no hard limit on the number of sources per notebook anymore, is there any practical limit imposed by the underlying LLM or retrieval pipeline?

For example:

Does retrieval quality degrade significantly when a notebook contains several hundred or thousands of documents?
Is there a recommended upper bound from a model or embedding/indexing perspective?
Are there any architectural considerations (context window, reranking, vector search, etc.) that users should be aware of when scaling to very large notebooks?

I'd like to understand whether the recommendation of 20–100 sources is purely for performance, or if it also helps maintain retrieval and answer quality.

[Jgmro]

Great follow-up. Digging into the architecture docs: each source is chunked into multiple SourceEmbedding rows, and Ask mode runs top-k vector search over those chunks before hitting the LLM — so the context window isn't the direct bottleneck; retrieval quality is. In vector search, larger corpora make semantically-nearby-but-irrelevant chunks more likely to compete for top-k slots, so the 20–100 recommendation probably serves both performance (embedding time, UI responsiveness) and retrieval focus. Embedding cost isn't a wall — it's batched via OPEN_NOTEBOOK_EMBEDDING_BATCH_SIZE (default 50) — and I didn't spot a reranker in the docs, which is usually where quality degrades first in large corpora. That said, this is inference from the design; @lfnovo would know the actual scaling behavior. Meanwhile, since Chat mode lets you toggle which sources are in context, a large notebook is workable if you activate subsets per session.

[lfnovo]

Moving this from Q&A to Ideas and broadening the title so it can serve as the canonical product Discussion for large notebooks and retrieval quality at scale.

There is no current hard limit on the number of sources in a notebook. The 20–100 figure in the FAQ is a practical rule of thumb, not a validated upper bound or a guarantee that quality changes at source 101. Document count alone is also a weak measure: ten books may contain more text than a thousand short notes.

The current constraints occur at several layers:

• ingestion time, embedding cost, index size, and storage grow with total content;
• Notebook Chat can be constrained by how much selected context fits in the configured language model;
• retrieval quality depends on chunking, embeddings, query behavior, corpus composition, and later reranking or synthesis—not only source count;
• local hardware and provider rate limits can dominate processing time long before the database reaches a structural limit.

Issue #473 tracks the larger RAG and context-selection architecture. Please use this Discussion for concrete corpus sizes, hardware/provider configurations, latency and quality observations, failure modes, and the benchmarks or controls users need. That evidence should help the architecture move from intuition to measurable targets.