Indexing Google Drive into a RAG with n8n: your internal documents, finally searchable

A small company's internal documentation rarely lives in a dedicated tool: it piles up in Google Drive — procedures, meeting notes, contracts, sales proposals. The result: the information exists, but nobody can find it. RAG (retrieval-augmented generation) answers exactly that problem, and its principle was laid out in the founding paper by Lewis et al. presented at NeurIPS 2020 ("Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", see on Google Scholar): rather than hoping a model "knows", you retrieve the relevant passages from a document base and hand them over at answer time — improving factuality and enabling source citations. What's left is feeding that base. Here's the complete n8n pipeline to index a Drive and keep it current.

Pipeline architecture

1. Detection: a Google Drive Trigger node watches the target folder (file creation and modification).
2. Download and extraction: the file is downloaded, Google formats (Docs, Sheets) are exported to text, PDFs and DOCX go through Extract From File.
3. Chunking: the text is split into overlapping chunks.
4. Embeddings and insertion: each chunk is vectorized then inserted into the vector store with its metadata (Drive file ID, name, modification date, folder).
5. Reindexing: when a file changes, its old vectors are deleted before the new ones are inserted.

For the vector store, the usual options apply: Supabase pgvector if you want to stay in SQL, Qdrant or Pinecone as dedicated engines. The examples below assume Supabase, like our free PDF-to-Supabase-pgvector ingestion workflow, of which this pipeline is the natural extension.

Step 1: watch the right scope

The Google Drive Trigger (OAuth2 credential — step-by-step setup here) is set on a specific folder and event type: File Created and File Updated. Two field-tested notes:

• The trigger works by polling: set the interval to the freshness you need (every 15 minutes is plenty for internal documentation).
• For a tree with subfolders, pair the trigger with a scheduled workflow (Schedule Trigger) that lists files modified since the last run and catches anything polling missed — the classic reconciliation pattern.

Filter file types upfront: indexing images, videos and archives only adds noise. An IF node on the MIME type keeps Docs, PDFs, DOCX and TXT.

Step 2: download and extract the text

The Download operation of the Google Drive node handles the subtlety of Google formats: a Google Doc isn't a file but an online document — the conversion option exports it as plain text or PDF at download time. Regular files (native PDFs, DOCX, TXT) then go through Extract From File. Scanned PDFs need OCR upstream, and spreadsheets deserve row-by-row treatment rather than raw extraction — see our guide to Excel and CSV files in n8n.

Step 3: chunking and embeddings

Splitting follows the rules from our guide to document chunking for RAG: 500-to-1,000-token chunks, 10-15% overlap, cuts on semantic boundaries. In n8n, the Default Data Loader and Recursive Character Text Splitter attached to the Vector Store node do this natively. For the embedding model, our embedding model comparison applies — the key rule being to never switch models without reindexing the whole corpus.

The decisive point for everything downstream: metadata. Store with each chunk the Drive file ID, its name, URL, modification date and parent folder. That's what enables clean reindexing, answers with clickable citations, and metadata filtering (say, restricting a search to HR procedures).

Step 4: reindexing, the real subject

The classic failure of Drive → RAG pipelines isn't at initial indexing but at update time: a modified document gets re-inserted without deleting the old vectors, and the store accumulates contradictory versions — the chatbot then cites the 2024 procedure next to the 2026 one. The correct sequence on every File Updated event:

1. Delete from the vector store every vector whose drive_file_id metadata matches the file (a direct SQL query with the Postgres node on Supabase).
2. Re-extract, re-chunk, re-insert.
3. Log it (file, chunk count, date) in a Data Table — your indexing dashboard.

Handle deletion too: a file removed from Drive must disappear from the index, or the RAG keeps citing a document the organization deliberately removed. The scheduled reconciliation workflow from step 1 is the natural place for that detection.

Querying: the part you already know

Once the Drive is indexed, querying is standard RAG: retrieval, generation with citations, and the usual refinements — hybrid search for exact terms (references, product names), reranking if relevance plateaus. The RAG Assistant Pack (€119) ships exactly that downstream half ready to plug in: a chatbot with citations, a question-answering API and Notion synchronization — the Drive pipeline from this article replaces or joins it as an ingestion source.

One governance point to close: the vector index knows nothing about Drive permissions. Only index what every chatbot user may read, or carry access rights as metadata and filter at query time. That's the difference between a documentation assistant and a well-organized internal data leak.