esqueleto

> Esqueleto offically supports a single database, Postgres. This is not so. It supports at least persistent-mysql, persistent-postgresql, persistent-sqlite, according to https://github.com/prowdsponsor/esqueleto/ Perhaps you are thinking of Opaleye, which does only support Postgres.

Honestly none of the statically typed sql generators (Opaleye included) really tick all the boxes; all are lacking in one way or another. Here's a breakdown of the leaders of the pack on this front[0] Haskell 1) Opaleye[1]: composable and prevents invalid sql, but no join support (simulated via sub selects), Postgres only, and tough syntax to parse. 2) Esqueleto[2]: composable, readable, supports joins, but Postgres only, and the DSL can't/doesn't prevent invalid sql (which is, IIRC, one of the reasons why Opaleye came into being). Scala 1) Slick[3] myriad databases supported (Oracle and SQL Server require non-free license), join support, fully composable (really, king of monad hill), and elegant syntax (until you `groupBy`/`sortBy` and then enter unreadble tuple_.1, tuple._N soup). Also, grouping requires flattening result set via min, m

> Esqueleto and OpalEye. The latter is fresh off the presses and not yet ready for prime time (see the "ideal sql" samples interspersed with the performance killing actual sql) On the contrary, Opaleye (lowercase "e") has been used in production to run multiple-hundred line queries with high performance. I gave the "idealized SQL" examples in the docs as a way of making the generated code easier to understand for readers, not to suggest that there is any performance loss. If you know of an example where the code generation leads to a performance loss in Postgres I would be interested to hear about it. (An aside: Esqueleto isn't anywhere close to typesafe, nor does the author claim this is one of its goals. It is trivial to produce crashing queries: https://github.com/prowdsponsor/esqueleto/issues/41)