As I’m polishing off the next version which currently is scheduled to be released in the coming weeks, and I got two exciting sneak peaks, we’re now more or less conformant with SQL 2016 with over 900 generated tests and SQL generation is 400-650x faster than Ecto.

I’m very excited for the new release of sql, which comes with best in class performance and memory usage, with a minimum of 50x compared to Ecto.

The test suite has also gotten an overhaul with over 900 test, testing the conformance of SQL 2016.

sql does now also supports prepared queries.

Checkout the sql/CHANGELOG.md at main · elixir-dbvisor/sql · GitHub for more!

We’ve happy to announce the release of 0.4.0, packed with performance and compile time improvements.

Screenshot 2025-10-18 at 4.32.08 PM1200×496 32.5 KB

Now as we can lex, parse and generate SQL faster then Ecto can at runtime, then we have moved our attention to implementing a SOTA pool, this will make it possible for us to aim at guaranteeing 100% cache hit on prepared queries, something I have never seen before and will have big impact on general performance.

Please see the sql/CHANGELOG.md at v0.4.0 · elixir-dbvisor/sql · GitHub for all details.

Yes, I’ve used that in the past, and I might use it for this in the future. But generated parsers does not come without it flaws.

For this project I wanted to see if we could get all the benefits of Ecto.Query and Elixir with its composability but with less abstraction and more control.

Enum.each(~SQL"...", fun) is really cool, I love stuff like that. By implementing Enumerable for %SQL{} ourselves we need to pick a particular repo which honestly is not that big of a deal, we tend to only have one anyway but still, it feels limiting.

WDYT about this?

  sql = ~SQL"..."
- Enum.each(sql, fun)
+ Repo.all(sql) |> Enum.each(fun)

i.e. instead of users implementing Enumerable themselves, SQL implements Ecto.Queryable!