Groundhog has design very similar to Persistent, so I would choose it for comparison. I don't have much of experience of using Persistent, so some facts may be inaccurate for the newer versions. The facts are based mostly on the Persistent documentation. You may be also interested in comparison of Persistent, HaskellDB, and Esqueleto from the announce of the library Esqueleto by Felipe Lessa http://blog.felipe.lessa.nom.br/?p=68 * Persistent creates both data definitions and auxiliary structures. This approach is not modular because it ties the data to a specific library. Groundhog examines existing data definitions defined in a normal way and uses this data to create the auxiliary structures. * Persistent entities always have autoincrement integer(for MongoDB bytestring) key. Groundhog entities may omit it and use a natural (composites are supported) key. An entity may have several keys. * Persistent stores embedded datatypes as a JSON string. Groundhog flattens the inner fields to several columns, which enables full access to inner fields of an embedded datatype. * Groundhog supports typesafe projections. Persistent can do them only with raw SQL or esqueleto. * Groundhog has expressive query DSL which enables comparing field-to-value, field-to-field, and use arbitrary arithmetic expressions. Persistent only supports field-to-value expressions with only one operator. * Groundhog does not support joins. Persistent supports only one-to-many joins for two tables, but esqueleto supports many types of joins for multiple tables. * Groundhog currently does not support Conduit or other resource-management libraries, IN clause, and migrations that add NOT NULL columns to non-empty tables. * Groundhog supports Sqlite and PostgreSQL. Persistent supports Sqlite, PostgreSQL, MySQL, and MongoDB. On Fri, Sep 14, 2012 at 1:28 AM, Tom Murphy wrote:

How does this compare with other high-level Haskell db libraries?

Tom

On Sep 13, 2012 2:25 PM, "Boris Lykah" wrote:

...

I am happy to announce a new version of Groundhog, a library for fast high-level database access: http://hackage.haskell.org/package/groundhog http://hackage.haskell.org/package/groundhog-th http://hackage.haskell.org/package/groundhog-postgresql http://hackage.haskell.org/package/groundhog-sqlite

Groundhog has been completely overhauled since the last release. Notably, it got support for PostgreSQL and natural foreign keys. I believe that it is a big step forward as this brings more flexibility to the design of the relational schemas while keeping the applications independent of the storage layer. Some of the solutions, particularly schema migration were based on Persistent code.

Please see examples at http://github.com/lykahb/groundhog/tree/master/examples.

Features: * Support for Sqlite and PostgreSQL. * Natural and composite foreign keys. Earlier it was possible to reference an entity only by the mandatory integer primary key. Now an entity can have several keys including autoincrement primary key (optional) and unique keys which have one or more columns. * Full support of embedded datatypes. You can access a field that contains an embedded datatype as a whole, or access some of the inner subfields individually. This powerful mechanism has allowed implementation of the composite keys, and can be used in future to work with PostgreSQL composite types or MongoDB embedded documents. Instead of serializing value to string, the Groundhog backends flatten tree of embedded datatypes to db columns. * Projections. You can choose what columns to query from a table in a type-safe manner. * Initialization and migration of database schema. * Sum types and polymorphic types. * Expression DSL for use in queries. * Basic list support. * YAML-based settings mechanism. It separates datatype definition and description which facilitates modularity. The settings are inferred from the analysis of the difinition, and overridden with values set by user.

The Criterion benchmarks are available at http://lykahb.github.com/groundhog/SqliteBench.html and http://lykahb.github.com/groundhog/PostgreSQLBench.html.

Future plans: * Support for joins * Database indexes * Investigate options for implementing MongoDB and MySQL backends

Your feedback, suggestions for improvement and criticism are welcome.

-- Regards, Boris

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Regards, Boris