There are two levels of integration that we could aim for: 1) at the TableTraits.jl level and 2) at the Query.jl level.
The 1) option should be pretty straightforward. Essentially we need to solve the two issues you identified, but that is pretty simple. I mainly just wanted to finish some under the hood refactoring with the iterable tables stuff, which is done now, so I might take a crack at this soon.
But 1) is actually pretty inefficient. For example, if you select a column via Query.jl, you will still transfer all the data from the database into main memory, just to discard it right away. It would be much more efficient to select that column in the SQL query itself, so that the DB engine never even loads any of the columns that you don’t need. This points to 2): Query.jl is actually designed in such a way that you can write a Query.jl query, and if the source is say a MySQL database, it will translate that Query.jl query into a SQL statement and then execute the whole query inside the database. There is one caveat: someone needs to write a Query.jl backend for MySQL that actually does this translation step, that part doesn’t exist yet. I have a very rudimentary backend for SQLite that can translate one very narrow type of Query.jl into SQL, more as a proof of concept that I got the architecture right. In generally, writing a backend is neither a trivial nor a small project and I probably won’t have time to pursue that in the near term. I might try to find some folks to work on this going forward, either here on campus or this would also make a nice Google Summer of Code project for next year.