That would be amazing, but potentially also misleading.<p>My 2 cents for Slava &amp; co: The idea of IQueryable&lt;T&gt; is that it implements all LINQ &quot;operators&quot; (a weird LINQ term; they&#x27;re just methods on an interface) just like IEnumerable&lt;T&gt; does it on in-memory data structures. But internally IQueryable&lt;T&gt; implementations typically build an SQL query instead.<p>So IQueryable&lt;T&gt; is designed for a use case somewhere halfway between an SQL query builder and an ORM.<p>I don&#x27;t know ReQL well enough, so you&#x27;ll have to assess this yourselves: If you can map all or most LINQ operators into ReQL, then you <i>have to</i> do the effort and implement IQueryable, it&#x27;s too awesome an opportunity to let go.<p>But if the match is only, say, 50%, plus there&#x27;s a couple of things Rethink can do that isn&#x27;t easy to express with LINQ, I&#x27;d <i>strongly recommend</i> not implementing it at all, but designing your own, C#-flavored, query interface that just <i>resembles</i> the LINQ operators wherever possible (e.g. use &quot;Where&quot; instead of &quot;filter&quot;).<p>Thing is, developers expect that anything they do on an IQueryable is transformed into a single gigantic query and optimized and executed once, on the database. Maybe Rethink can&#x27;t guarantee the same performance characteristics, simply because it&#x27;s no relational SQL-ish database. It would have to implement certain parts of IQueryable in client-side memory just to be compatible. Do that, and you&#x27;ll end up fooling a lot of developers and they&#x27;ll have a hard time finding out where their speed went. The other option is runtime NotImplementedExceptions for all unsupported methods, which really is just as unfriendly.