authors/bcardiff.jpg Brian J. Cardiff 26 Dec 2016

INSERT INTO shard VALUES ("crystal-db")

Using a database is a really common task. For each kind of database there is a shard or library needed. When there is no common API to talk to a database, building more advanced shards like orm or migrations is harder. Either you end up supporting just a driver or you need to create a whole ad-hoc solution. Lacking a common api also means that when changing from one DB to another you will need to learn a different api. You already unavoidably need to deal with some SQL differences: ?/$1, TOP/LIMIT, etc.

Some time ago we started crystal-lang/crystal-db to build a unified database API.

We are proud to announce that we have reached the point where it is no longer a proof-of-concept. We are excited to share the latest news, and encourage you to use and break things.

The role of crystal-db is to abstract from SQL DB drivers which will implement bindings or even raw protocols using Socket.

Current crystal-db implementations are:

Why are 100% crystal implementations important? Usually this means:

  • Less pain with binary dependencies,
  • You can go down the rabbit hole with protocols.

But even more important:

  • Reduce memory footprint,
  • Read/write directly on the socket to the server without leaving the joy of the language,
  • Take advantage of all the native async I/O in crystal, thus not blocking the current fiber.

Also, besides a unified query API, crystal-db ships with a connection pool, prepared statements, and nested transactions.

However, keep in mind that the role is not to abstract the particularities of different SQL dialects: while the shard provides a common API for writing SQL queries as strings, it does not attempt to analyse and manipulate the SQL code itself

Next steps

We need to improve the documentation. Besides using crystal docs, a new section was added to crystal-book that will continue to grow in the near future.

We hope this will help build DB tools and shards that work with multiple drivers, and that it will encourage more people to build their own drivers.

Special thanks

Using a database is a really common task. For each kind of database there is a shard or library needed. When there is no common API to talk to a database, building more advanced shards like orm or migrations is harder. Either you end up supporting just a driver or you need to create a whole ad-hoc solution. Lacking a common api also means that when changing from one DB to another you will need to learn a different api. You already unavoidably need to deal with some SQL differences: ?/$1, TOP/LIMIT, etc.

Some time ago we started crystal-lang/crystal-db to build a unified database API.

We are proud to announce that we have reached the point where it is no longer a proof-of-concept. We are excited to share the latest news, and encourage you to use and break things.

The role of crystal-db is to abstract from SQL DB drivers which will implement bindings or even raw protocols using Socket.

Current crystal-db implementations are:

Why are 100% crystal implementations important? Usually this means:

  • Less pain with binary dependencies,
  • You can go down the rabbit hole with protocols.

But even more important:

  • Reduce memory footprint,
  • Read/write directly on the socket to the server without leaving the joy of the language,
  • Take advantage of all the native async I/O in crystal, thus not blocking the current fiber.

Also, besides a unified query API, crystal-db ships with a connection pool, prepared statements, and nested transactions.

However, keep in mind that the role is not to abstract the particularities of different SQL dialects: while the shard provides a common API for writing SQL queries as strings, it does not attempt to analyse and manipulate the SQL code itself

Next steps

We need to improve the documentation. Besides using crystal docs, a new section was added to crystal-book that will continue to grow in the near future.

We hope this will help build DB tools and shards that work with multiple drivers, and that it will encourage more people to build their own drivers.

Special thanks

comments powered by Disqus