I'd love to see this too. I've only used HDBC and I think it works well. A common problem in the Haskell-community is that some produce low-level bindings/libs and some produce high-level (extremely type safe) bindings/libs but there's seldom good support for switching between or combining the two approaches. My experience is that when it comes to real world scenarios involving databases/xml/json/&c you are seldom able to figure out *all* types compile time and are thus forces to use the low-level lib for everything even though you got the types (e.g. of a table/view/function/...) at compile time for 90% of your code. That's a shame and something that I wish a merging between the packages would be able to solve. In other words: a good package should support more than one way to interface with the db and the different ways should be possible to seamlessly combine. My wish-list: * low level capabilities a la HDBC * high level capabilities (matching result sets to data types, db functions <-> haskell type classes or similar) * sql 2003/2008-, pl/sql-quasi quoter * code generation given a db schema. * schema generation from code (i.e. the opposite from the above). * fixture generation (Haskell -> db, db -> Haskell) * syb-support * BSD3 or DWTFYWT * github :) I'm prepared to spend a couple of hours a week helping out and I got some experience developing database layers that's used in telecom, gaming and logistics. -- Oscar P.S. I'm not saying that there should be only one; competition is always good. It would however be lovely if the community made an effort to (a) produce an package that can cover mosts needs that (b) most developers/package-maintainers used that (c) other developers can build upon with new features.