A bit late to this party, but …
On the name of the library
Calling the library SQL seems a dubious choice, to put it kindly.
SQL is a standard (more or less 
) and there are various libraries out there that provide various types of SQL features. Now there’s a library name-squatting on that technology by its name on hex.pm.
There are a sad number of libraries on hex.pm that already name-squat on the broadest possible names, too many of which are some combination of incomplete, abandoned, or not the best option anymore. Searching for those broad names still brings them up, making it often much harder than it should be to find the actually relevant choices on hex.pm.
It would be great to not replicate that with yet another library calling itself the name of the thing it provides.
Imagine if Ecto had been called SQL. What then for your library?
Extensibility
How does one add data types?
I work with a number of custom datatypes and have various means of working with Ecto on utilizing them across various backends. Libraries like geo_sql rely on this to work with WKT/WKB types as stored and returned by various database GIS implementations.
How would one add support for another DB, such as SQLite?
Will it eventually be possible to use existing and more complete librareis such as postgrex for backend access, or is the plan for SQL to always ship its own hand-rolled implementations?
(See how the name of the library makes it harder to have these sorts of conversations? When I write “for SQL to always” do I mean the library, the language, a given query, …)
Interop
Are there any thoughts/plans on interop with Ecto, or will these be two separate walled gardens going forward?
Composition
If one writes something like: ~SQL[from users where foo = 2 select id, email] |> ~SQL[where bar = 2]it ends up with 2 where clauses, and this causes an error. Same for any other clause for that matter. Will this library eventually support actual composibility of queries? This is a feature provided by Ecto which is absolutely invaluable.
The composability also seems somewhat fragile? e.g.:
sql = ~SQL[from users u]
|> ~SQL{where u.email = 'john@example.com'}
|> ~SQL{where u.email = 'john@example.com'}
|> ~SQL{foosball}
|> ~SQL[select id, email, inserted_at, updated_at]
Produces: “foosball where u.email = ‘john@example.com’ where u.email = ‘john@example.com’ from users u select id, email, inserted_at, updated_at” Note how the select statement is suddenly at the end.
Moving the select above the foosball bit puts the select in its correct position.
Is this resolvable in the library, or is the expectation that the user of the library always places things in a sensible order?
I appreciate that there is a focus on performance in this library, but if things don’t work it makes it hard to consider as an option.
p.s. The LetsEncrypt-issued SSL cert on dbvisor expired in September. 
