What are the tradeoffs between the Haskell SQLite packages?

I looked at the package mentioned. Some of these package are a dependency of another package (like opaleye-sqlite and sqlite-simple) depend on direct-sqlite.

Therefor lets first look at the package that provide the actual driver. Most of them are outdated. There seem to be 3 that still have recent updates:

• https://hackage.haskell.org/package/simplest-sqlite https://github.com/YoshikuniJujo/test_haskell/tree/master/features/ffi/sqlite3/simplest-sqlite i wouldn't use it because the repository says "It's just my private Haskell learning/testing repository."

• https://hackage.haskell.org/package/persistent-sqlite this one is based on direct-sqlite (seems like part of the direct-sqlite has been forked)

• The last one being the direct-sqlite package. I used this website to find which package depend on direct-sqlite. Now leaving out package that don't have the purpose of working with sqlite (such as bake: Continuous integration system). And also leaving out packages that haven't seen updates in a long time.

That leaves us with the following package that provide extra functionality based on direct-sqlite. This list includes more levels of reverse lookup to see which other package make use of the package listed below.

• persistent-sqlite as mentioned before

  • esqueleto
  • eventful

• groundhog-sqlite

• opaleye-sqlite
• selda-sqlite
• sqlite-simple
  • beam-sqlite

I've had very good experiences with the ...-simple family of libraries. They are very full-featured and sit at a nice medium level of abstraction where you get a large amount of flexibility over how you intereact with the database.

I'm the author of opaleye-sqlite. It is a somewhat experimental version of Opaleye for SQLite. The Postgres version of Opaleye is very solid and used in production in several places, but I only know of one person who has used opaleye-sqlite in production.