Minor aside; we've had multiple suggestions to the OP that a database
is the right way to go here [hint: it really is!] - but if the OP is
worried about being to support both in-memory and disk (database)
based queries, then perhaps LINQ-to-SQL has the answer?

i.e. use LINQ to generate the entities (otherwise it'll never work
later), but in your code simply work with IQueryable<Whatever>, and
supply the source at runtime (based on the data volume).
For instance, a List<Whatever> will work just fine
with .ToQueryable(), but so will a Table<Whatever>.

Note that obviously the list won't automatically be indexed of course.

Actually, even the above is probably over-designing it. Keep it simple
and code to the worst-case scenario: use the database approach from
the outset. If it is running locally, then it should be pretty quick
regardless of the data volume (or at least, the performance will
degrade at an acceptable rate, unlike in-memory which doesn't scale so
well). If you need more data, buy a bigger database (i.e. start with
SQL Express).

Marc

An in-memory collection whose contents are being paged to and from the
disk by the OS will have worse performance than a collection designed
to operate off the disk, as soon as you do any kind of search on it.

A collection that's designed to run off the disk will probably have an
indexing system so it doesn't have to load the entire file to find a
single element. But searching through a massive memory-based
collection will cause many pages to be swapped in, possibly causing
other useful pages to be swapped out and lowering performance down the
road.

For example, a binary search on a memory-based collection might end up
having to load half the file into memory, one page at a time, while a
disk-based collection could keep all the necessary indexing data in a
single page that never gets swapped out.

Jesse