Memory issue iOS

It's a guest list system administered through an iPad. Normally around 2000 guests, but making sure I can deal with more. If the wifi/data connection drops I need to be able to still search the backend store for guests and admit them, and then sync changes back when the connection restores. 

Not really, the problem is that a breeze "entity" is defined by its collection of properties, and with your 'projected' entity many of these properties will not be populated.  This will cause problems if you were to try, for example, to modify and save it. 

What you can do fairly easily if you have projected the field or fields that make up an entities key value, is to construct a new query for the entity using the key value or values and "requery" just those entities that you want to work with at a point in time.  These entities will be brought into the cache and may be modified and then saved.  If you want to keep the cache size down, you can then detach them and query for the next set of entities that you want to work with.

Does this make sense?

Ok, I think there are a few different routes you could go down

1) make each of the entities "smaller"

This would mean 'shrinking' the surface of your entities on the server. Probably not terribly feasible for a lot of apps.  But we are also looking at mechanisms for controlling serialization and allowing the developer to expose only a subset of the server model to the client.  

2) have some of the most voluminous queries return projections instead of full entities.

Projections are queries using the "query.select" method.  For example

var query = EntityQuery("Orders")
    .where("Customer.CompanyName", "startsWith", "C")         
    .select("Customer.CompanyName, Customer.Region, OrderDate, OrderDetails");

The advantage of projections is that any projected property that is not an entity or an entity collection is not wrapped by breeze in an "observable" wrapper (knockout, backbone etc.).  These wrappers can take up memory especially if you have a lot of them; this combined with the idea that you are only bringing down a subset of each entity can make your app's memory footprint much smaller.  In the query above "Customer.CompanyName", "Customer.Region" and "OrderDate" will all be brought to the client as "simple" scalar values instead of entities, whereas "OrderDetails" will be brought in as an array of  breeze 'OrderDetail' entities each wrapped in its own "observable" wrapper.

3) Avoid query.expand operations

- these are great for caching data, but do tend to have large payloads.

4) Break the query up into several smaller queries. 

Ok, I'm just guessing here because I do not know where the IOS memory limits that you are hitting are but it is conceivable that the issue is not total memory use, but rather a memory spike that occurs when deserializing the entities after a large query.  In this case, creating several smaller queries and executing them in series might work.

Hope this helps!