Announcing Diesel 1.0 — A Safe, Extensible Query Builder and ORM

Yesterday, Diesel released its first stable release. Diesel is the most productive way to interact with databases in Rust. Now that we’ve entered a period of stability, let’s take a look at what Diesel is about, and what makes it different.

Truly Type Safe

Diesel’s core goal is to prevent most runtime errors at compile time. To do this, we create a representation of your database schema in Rust’s type system. We use this information to type check your entire query, and ensure it is semantically valid. This ranges from simple things like ensuring that nulls are handled properly, to more complex cases like disallowing mixing aggregate and non-aggregate expressions in the same select clause.

You’ll find Diesel’s API inspired by projects from dynamically typed languages, such as SQLAlchemy. However, you’ll find that our level of type safety matches that of Haskell libraries like opaleye.

Built for Speed

Diesel’s type safe structure also enables it to be incredibly fast, beating most other libraries/languages (including C). For example, since Diesel represents your query in Rust’s type system, we are able to identify most queries by its type alone. This means that we can retrieve a query from the prepared statement cache without constructing the SQL at all. This means that Diesel’s query builder is often faster than using a SQL string directly.

Additionally, since we are able to know the database representation of a query at compile time, the serialization and deserialization code that we generate can be very specifically structured for the exact query you are executing, eliminating most runtime checks. This is the sort of code that an optimizing compiler loves, and causes Diesel’s deserialization to be truly zero cost. The final assembly will be what you would have written by hand.

Query Builder First, ORM Second

The term “ORM” comes with a lot of baggage. Given that Diesel maps your relational database to Rust objects, the label definitely applies. However, you’ll find that Diesel is different from other ORMs you may be used to.

We are a query builder first. There should never be any mystery about what query is generated by a piece of Rust code.

We embrace using your database where it makes sense. Diesel has no concept of callbacks or “automagically” handling certain columns. Instead we encourage the use of database triggers, and utilize the RETURNING keyword to retrieve data.

Unlike most ORMs, we don’t assume that your application’s domain structures will map one-to-one with your database tables. Instead we focus on “the results of SQL queries” for SELECT statements, and structures that will closely mirror your input for INSERT and UPDATE statements.

Built for Composition and Extension

We don’t pretend to support every possible database extension out there. However, Diesel was designed from the ground up to be extended with whatever functionality you need. This means that custom SQL functions are trivial to represent in our query builder, and you can also support your own types.

Diesel is also structured to be abstracted over. The main benefit of using a query builder over raw SQL is the ability to reuse code, and we’ve designed our API with that use case in mind.

Production Ready

Diesel 1.0 is already being used in production by many companies. Rust itself uses it for its package registry. We hope you’ll give our first stable release a try. You can find more information as well as comprehensive guides on our website diesel.rs