RAG for CSV and structured data: when not to use RAG at all
Vector search over structured rows answers approximately what a SQL query answers exactly, so the useful question for CSV data is which parts belong in a RAG corpus at all.
When should you not use RAG for CSV?
Vector search over structured rows answers approximately what a SQL query answers exactly, so the useful question for CSV data is which parts belong in a RAG corpus at all.
RAG is a bad database
If your question is 'how many orders shipped late in March', that is a query with an exact answer. Embedding the rows and searching by similarity gives you an approximate one, more slowly. Retrieval is for prose, where there is no query language.
Row-per-chunk needs the header on every row
Where you do convert tabular data, each passage must carry its column names. A bare row is uninterpretable both to the embedding model and to whoever reads the retrieved chunk. 'region=EMEA, quarter=Q3, revenue=412000' retrieves; 'EMEA,Q3,412000' does not.
The description column is usually the real content
Most business CSVs have one or two free-text columns - notes, descriptions, ticket bodies - surrounded by identifiers and numbers. Those columns are genuine RAG material. Converting them and leaving the rest in the database is usually the right split.
Hybrid beats either alone
The strongest pattern is a system that queries the database for facts and retrieves passages for explanation, then answers from both. Deciding which half each question needs is a routing problem, not a conversion problem. Under the hood that conversion is Remade with Rust: memory-safe libraries compiled for local and API paths alike.