Solr indexes text. Binary data sent as a field value (a picture, a PDF, an attachment, a serialized object, encoded as base64) is the fastest way to make an index huge, slow and unstable. It is never searched, and it is paid for on every request.
Every base64 string is a pile of unique terms
Base64 is random characters. Cut into words or n-grams, almost every piece is a term no other document has, so the term dictionary grows with every file and nothing of it is ever matched by a real search. Nobody types iVBORw0KGgo into a search box.
Indexing memory grows with the field
Solr builds all the terms of a document in memory before it writes the document. One field holding a megabyte of base64 can need hundreds of megabytes, sometimes gigabytes, of heap for that single document: enough to stall indexing for the whole index, or to make the server run out of memory and restart.
Stored copies travel everywhere
A stored field is written to disk, returned in every response that lists it, and copied to every replica. A field that carries files multiplies disk use, response size and transfer volume for no search value.
What to send instead
Keep the file in your storage or CDN and send Solr a reference to it (a URL or an id) plus the text that describes it: title, caption, alt text, or the text extracted from a PDF or office document. That text is what people search for.
{ "id": "article-42", "title": "How to brew arabica coffee", "image_url": "https://cdn.example.com/img/arabica.png", "image_alt": "Arabica beans on a wooden table", "body": "Plain text of the article, without markup and without embedded files." }
How to check your index
Look for field values that start with data: or contain long runs of letters and digits without spaces, and for documents whose stored text is far larger than what a visitor reads on the page. One such document can weigh more than a thousand normal ones.
Solr best practices
Never put binary data or base64 into Solr (this page)