 <p>The <code>OutOfMemoryException</code> is almost certainly coming from the JSON serialization of your <code>Customer</code> object. As such, the issue isn't one of NEST or Elasticsearch functionality, but of JSON.NET functionality.</p> <p>You could handle this in one of two ways:</p> <p><strong>1. Serialize the large object selectively</strong></p> <p><a href="http://james.newtonking.com/archive/2009/10/23/efficient-json-with-json-net-reducing-serialized-json-size" rel="nofollow">This article</a> by the author of JSON.NET discusses reducing the size of objects. You might furnish properties with the <a href="http://www.newtonsoft.com/json/help/html/T_Newtonsoft_Json_JsonIgnoreAttribute.htm" rel="nofollow">JsonIgnoreAttribute property</a> to instruct the serializer to ignore certain properties. Or an implementation of <a href="http://www.newtonsoft.com/json/help/html/T_Newtonsoft_Json_Serialization_IContractResolver.htm" rel="nofollow">IContractResolver</a> may be less intrusive on the definitions of your EF objects (especially given that they're database-first generated), but I'm not sure whether this can be used in conjunction with the NEST dependency on JSON.NET.</p> <p>If you're out of options for dealing with NEST's dependency on JSON.NET, you could always find another way to serialize your object and "go raw" by using the Elasticsearch.NET syntax instead of NEST (which essentially builds on-top of Elasticsearch.NET). So instead of a call to <code>ElasticClient.Index(..)</code>, make a call to <code>ElasticClient.Raw.Index(..)</code>, where the <code>body</code> parameter is a JSON string representation (of your own construction) of the object you wish to index.</p> <p><strong>2. Project the large object to a smaller data transfer object</strong></p> <p>Instead of indexing a <code>Customer</code> object, map only the properties you want to index into a data transfer object (DTO) that targets your Elasticsearch schema / document type.</p> <pre><code>foreach (Customer c in db.Customer.Where(a =&gt; a.Active == true)) client.Index(new MyElasticsearchTypes.Customer() { CustomerId = c.CustomerId, CustomerName = c.CustomerName, Description = c.Description }); </code></pre> <p>In C#, you've got a lot of options for how to handle creation of such a DTO, including:</p> <ol> <li>Explicitly typed objects with manual mapping (like my example).</li> <li>Explicitly typed objects with a mapping tool like <a href="https://www.nuget.org/packages/AutoMapper/" rel="nofollow">AutoMapper</a>.</li> <li>Dynamic objects.</li> </ol> <p><strong>Flat by design</strong></p> <p>Be aware that using Elasticsearch isn't a case of simply throwing your data into "the index". You need to start thinking in terms of "documents", and come to terms with what that means when you're trying to index data that has come from a relational database. The Elasticsearch guide article <a href="http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/data-in-data-out.html" rel="nofollow">Data In, Data Out</a> is a good place to start reading. Another article called <a href="http://www.elasticsearch.org/blog/managing-relations-inside-elasticsearch/" rel="nofollow">Managing relations inside Elasticsearch</a> is particularly relevant to your situation:</p> <blockquote> <p>At it's heart, Elasticsearch is a flat hierarchy and trying to force relational data into it can be very challenging. Sometimes the best solution is to judiciously choose which data to denormalize, and where a second query to retrieve children is acceptable</p> </blockquote>