HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
diesel-rs
diesel
Rust2016–2025
diesel-rs / diesel

diesel

A safe, extensible ORM and Query Builder for Rust

21Distinct people
25Mentions
0Explicit recommenders
14.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A safe, extensible ORM and Query Builder for Rust

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:38:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year25 dated mentions

Observed mentions: 2016-04-19 22:43:29 UTC to 2025-07-28 21:32:01 UTC.

0123452016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC312
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC514
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC413
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC514
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC202
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC404
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
A safe, extensible ORM and Query Builder for Rust API Documentation: latest release – main branch Homepage Diesel gets rid of the boilerplate for database interaction and eliminates runtime errors without sacrificing performance. It takes full advantage of Rust's type system to create a low overhead query builder that "feels like Rust." Supported databases: PostgreSQL MySQL SQLite MariaDB You can configure the database backend in Cargo.toml: [dependencies] diesel = { version = "<version>", features = ["<postgres|mysql|sqlite>"] } Getting Started Find our extensive Getting Started tutorial at https://diesel.rs/guides/getting-started. Guides on more specific features are coming soon. Getting help If you run into problems, you can come ask for help at in our GitHub Discussions forum. This is also the right place to propose new features or show your applications. Usage Simple queries Simple queries are a complete breeze. Loading all users from a database: users::table.load(&mut connection) Executed SQL: SELECT * FROM users; Loading all the posts for a user: Post::belonging_to(user).load(&mut connection) Executed SQL: SELECT * FROM posts WHERE user_id = 1; Complex queries Diesel's powerful query builder helps you construct queries as simple or complex as you need, at zero cost. let versions = Version::belonging_to(krate) .select(id) .order(num.desc()) .limit(5); let downloads = version_downloads .filter(date.gt(now - 90.days())) .filter(version_id.eq_any(versions)) .order(date) .load::<Download>(&mut conn)?; Executed SQL: SELECT version_downloads.* FROM version_downloads WHERE date > (NOW() - '90 days') AND version_id = ANY( SELECT id FROM versions WHERE crate_id = 1 ORDER BY num DESC LIMIT 5 ) ORDER BY date Less boilerplate Diesel codegen generates boilerplate for you. It lets you focus on your business logic, not mapping to and from SQL rows. That means you can write this: #[derive(Queryable, Selectable)] #[diesel(table_name = downloads)] pub struct Download { id: i32, version_id: i32, downloads: i32, counted: i32, date: SystemTime, } Instead of this without Diesel: pub struct Download { id: i32, version_id: i32, downloads: i32, counted: i32, date: SystemTime, } impl Download { fn from_row(row: &Row) -> Download { Download { id: row.get("id"), version_id: row.get("version_id"), downloads: row.get("downloads"), counted: row.get("counted"), date: row.get("date"), } } } Inserting data It's not just about reading data. Diesel makes it easy to use structs for new records. #[derive(Insertable)] #[diesel(table_name = users)] struct NewUser<'a> { name: &'a str, hair_color: Option<&'a str>, } let new_users = vec![ NewUser { name: "Sean", hair_color: Some("Black") }, NewUser { name: "Gordon", hair_color: None }, ]; insert_into(users) .values(&new_users) .execute(&mut connection); Executed SQL: INSERT INTO users (name, hair_color) VALUES ('Sean', 'Black'), ('Gordon', DEFAULT) If you need data from the rows you inserted, just change execute to get_result or get_results. Diesel will take care of the rest. let new_users = vec![ NewUser { name: "Sean", hair_color: Some("Black") }, NewUser { name: "Gordon", hair_color: None }, ]; let inserted_users = insert_into(users) .values(&new_users) .get_results::<User>(&mut connection); Executed SQL: INSERT INTO users (name, hair_color) VALUES ('Sean', 'Black'), ('Gordon', DEFAULT) RETURNING * Updating data Diesel's codegen can generate several ways to update a row, letting you encapsulate your logic in the way that makes sense for your app. Modifying a struct: post.published = true; post.save_changes(&mut connection); One-off batch changes: update(users.filter(email.like("%@spammer.com"))) .set(banned.eq(true)) .execute(&mut connection) Using a struct for encapsulation: update(Settings::belonging_to(current_user)) .set(&settings_form) .execute(&mut connection) Raw SQL There will always be certain queries that are just easier to write as raw SQL, or can't be expressed with the query builder. Even in these cases, Diesel provides an easy to use API for writing raw SQL. #[derive(QueryableByName)] #[diesel(table_name = users)] struct User { id: i32, name: String, organization_id: i32, } // Using `include_str!` allows us to keep the SQL in a // separate file, where our editor can give us SQL specific // syntax highlighting. sql_query(include_str!("complex_users_by_organization.sql")) .bind::<Integer, _>(organization_id) .bind::<BigInt, _>(offset) .bind::<BigInt, _>(limit) .load::<User>(&mut conn)?; Code of conduct Anyone who interacts with Diesel in any space, including but not limited to this GitHub repository, must follow our code of conduct. License Licensed under either of these: Apache License, Version 2.0, (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0) MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT) Contributing Before contributing, please read the contributors guide for useful information about setting up Diesel locally, coding style and common abbreviations. Unless you explicitly state otherwise, any contribution you intentionally submit for inclusion in the work, as defined in the Apache-2.0 license, shall be dual-licensed as above, without any additional terms or conditions. Notable Sponsors and Supporters We would like to thank all of the sponsors supporting the work on Diesel. Notable large sponsors are: NLNet Foundation Prototype Fund GitHub Secure Open Source Fund NGI Zero Core Federal Ministry o
Read the full README on GitHub

What Hacker News says

3 sources
The Bike Shed [0] is great, I think it started as a ThoughtBot podcast, but one of the two regular hosts - Sean Griffin [1] - has since left for Shopify. I think it's great because although dominated by Ruby (Griffin is a committer on Rails, and I gather it's ThoughtBot's main language) the discussion is typically applicable to other languages, or focuses on a human element. I don't think I've ever written a line of Ruby, and I enjoy it. There's also some Haskell discussion and more recently a lot of Rust - Griffin having created the Diesel ORM [2]. The format's great though, and as a consequence never sounds like a contrived dialogue - it typically starts as a "what have you been working on this week", and that recent real experience turns into a more general discussion around whatever it was. I can't really recommend it enough, I only f
Read the rest
ound it fairly recently, and went back through to listen to the entire catalogue of episodes. - 0: https://thebikeshed.fm - 1: https://githib.com/sgrif - 2: https://github.com/diesel-rs/diesel
In Ask HN: What software engineering related podcasts are you listening to?
One ORM I've used recently which does some cool stuff is Diesel, for Rust. On a few of these counts, I think it does quite well: > Efficiency is "good enough": none of the ORM layers I've seen claim efficiency gains. They are all fairly explicit that you are making a sacrifice of efficiency for code agility. If things get slow, you can always override your ORM methods with more efficient hand-coded SQL. Right? Relevant GitHub PR: https://github.com/diesel-rs/diesel/pull/283 -- Diesel's query builder is often faster than a raw SQL string, and the queries are typechecked against a provided database schema at compile time. > When you fetch an object, which of its properties (columns in the table) do you need? ORM can't know, so it gets all of them (or it requires you to say, breaking the abstraction). Initially this is not a problem, but whe
Read the rest
n you are fetching a thousand records at a time, fetching 30 columns when you only need 3 becomes a pernicious source of inefficiency. This is trivially easy to avoid in Diesel (and, I suspect, in other ORMs I haven't yet used. Just add a .select((tuple, of columns)) function call to the start of any query you're building. > Entirely anecdotally, I claim that the abstraction of ORM breaks down not for 20% of projects, but close to 100% of them. IMO a good ORM allows seamless integration of "raw" SQL through the use of type-checked function calls which integrate into the rest of the ORM. Diesel does this, and IIRC so does SQLAlchemy. > Objects are not an adequate way of expressing the results of relational queries. Right. But an ORM need not always force returning objects. Diesel (and again, IIRC SQLAlchemy) are examples.
In ORM is an anti-pattern (2011)

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.