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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 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

25 sources
How long ago did you try SQLx? Not necessarily promoting SQLX, but the `query_as` which lets one make queries without the live database macro has been around for 5 years [1]. For lower level libraries there is also the more downloaded SQLite library, rusqlite [2] who is also the maintainer of libsqlite3-sys which is what the sqlite library wraps. The most pleasant ORM experience, when you want one, IMO is the SeaQl ecosystem [3] (which also has a nice migrations library), since it uses derive macros. Even with an ORM I don't try to make databases swappable via the ORM so I can support database-specific enhancements. The most Rust-like in an idealist sense is Diesel, but its well-defined path is to use a live database to generate Rust code that uses macros to then define the schema-defining types which are used in the row structs type/memb
Read the rest
er checking. If the auto-detect does not work, then you have to use its patch_file system that can't be maintained automatically just through Cargo [4] (I wrote a Makefile scheme for myself). You most likely will have to use the patch_file if you want to use the chrono::DateTime<chrono::Utc> for timestamps with time zones, e.g., Timestamp -> Timestamptz for postgres. And if you do anything advanced like multiple schemas, you may be out of luck [5]. And it may not be the best library for you if want large denormalized tables [6] because compile times, and because a database that is not normalized [7], is considered an anti-pattern by project. If you are just starting out with Rust, I'd recommend checking out SeaQl. And then if you can benchmark that you need faster performance, swap out for one of the lower level libraries for the affected methods/services. [1] https://github.com/launchbadge/sqlx/commit/47f3d77e599043bc2... [2] https://crates.io/crates/rusqlite [3] https://www.sea-ql.org/SeaORM/ [4] https://github.com/diesel-rs/diesel/issues/2078 [5] https://github.com/diesel-rs/diesel/issues/1728 [6] https://github.com/diesel-rs/diesel/discussions/4160 [7] https://en.wikipedia.org/wiki/Database_normalization
In SQLx – Rust SQL Toolkit
I think you are talking past each others. Preventing N+1 by doing lazy fetching and having synchronous / asynchronous API are orthogonal issues. Async API must not block the thread/event loop when the data loading is being done. Diesel hasn't been providing an async API for reason told in this thread: https://github.com/diesel-rs/diesel/issues/399 The situation might change some day though, once async support in the core language and surrounding ecosystem gets stronger.
In Toasty, an async ORM for Rust
Here is another thing worth sharing. Database integration tests on Bazel used to be difficult. Ultimately I've found an elegant solution: https://github.com/diesel-rs/diesel/blob/master/examples/pos... The parallel testing with dangling transactions isn't Diesel or Postgres specific. You can do the same with pure SQL and any relational DB that supports transactions. For CI, BuildBuddy can spin up Docker in a remote execution host, then you write a custom util that tests if the DB container is already running and if not starts one, out that in a test and then let Bazel execute all integration tests in parallel. For some weird reasons, all tests have to be in one file per insolated remote execution host, so I created one per table. Incremental builds that compile, tests, build and publish images usually complete in about one minute. That's
Read the rest
thanks to the 80 Core BuildBuddy cluster with remote cache. GitHub took about an hour back in April when the repo was half in size. There is real gain in terms of developer velocity.
In Rust in illumos
There are some similar projects, like sqlx [1] for Rust. My problem with these is that they don't help to solve the actually hard problems. While nice to have, preventing bugs with static SQL is usually easy to do by writing a few tests. Most of the SQL related bugs I have encountered were due to queries with dynamic/conditional joins, filters and sorting - and almost every project using a database needs those. Approaches like this don't help there. That requires heavy-weight solutions that are more cumbersome to use and need a strong type system, like diesel [2] (Rust), Slick [3] (Scala) and some similar Haskell projects. [1] https://github.com/launchbadge/sqlx [2] https://github.com/diesel-rs/diesel [3] https://scala-slick.org/
In Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres
There is only one option: diesel [1]. It is a powerful solution for correctness, as it is completely type-safe. It's also really fast since a lot of work is delegated to compile time. There are also plenty of drawbacks though: the extensive type system hacking can lead to very confusing compiler errors, it doesn't work well when you need to sometimes fall back to more dynamic db handling, and it doesn't handle large tables well. (very long compile times etc), and the documentation is quite sparse. It's a robust solution for greenfield projects where you can design the schema partially with diesel in mind, but I wouldn't recommend it for existing DBs or projects that you know will grow large (eg 100+ column tables etc). [1] https://github.com/diesel-rs/diesel
In Actix-web 1.0 – A small, pragmatic, and fast web framework for Rust
> I thought you hated connection pools? No, you're just being unnecessarily rude. I just said I thought that fine-grained checkin-checkout like Go and Rust encourage is somewhat overrated. There's no need to be hostile. > Postgres specifically supports unnamed prepared statements as a feature, and PgBouncer's model cannot do anything to help those. PqExecParams (single phase prepared statement) works fine over PgBouncer. That's what I'm talking about. This is different to PREPARE & EXEC. You can't actually do a single phase prepared statement from psql, AFAIK, only via client libraries. https://www.postgresql.org/docs/11/libpq-exec.html I agree, the PgBouncer documentation could be clearer. I think they just don't want people trying it to file bug reports. PREPARE and EXEC can actually work even over statement pooling but you need to make
Read the rest
sure your connection setup statements prepare all the necessary statements. > it's a synchronous process, unless you specifically launch that query in its own separate goroutine You're right, I'm getting two things mixed up here. It is a while since I dealt with this problem. 1) The auto-checkout can mean you end up executing related statements on different connections. IMHO this is highly confusing to have as default behaviour and I prefer the Rust approach. 2) By default Go will just keep piling up Goroutines blocked on slow queries and open more DB connections and kill a DB server. Reference for both: http://go-database-sql.org/connection-pool.html > Rust database pools provide an option to limit the upper bound If you're using Rust + Diesel + PG it's actually limited to 10 by default via R2D2: https://github.com/sfackler/r2d2/blob/ad9cdb9f1446c729240cf8... I really think that's a lot saner than "open as many DB connections as you like, what could possibly Go wrong" If you don't believe me that Diesel and single phase prepared statements work with PgBouncer, believe the Diesel maintainer, Sean Griffin: https://github.com/diesel-rs/diesel/issues/1028 I'm back to working in Rust again and plan on opening a PR to resolve this issue.
In Fibers are the right solution to improve Ruby performance
Oh, I should've worded it better. It turns out it's pretty easy to set up Diesel to test your application code together with setting up a lock Postgres database. I had to put it up myself, but overall I just copied the approach Diesel uses for it's own integration test: have a test subproject and set up the database in it's custom compilation script. https://github.com/diesel-rs/diesel/tree/master/diesel_tests Now, every time I alter application code and/or SQL migrations, I immediately test them together automatically.
In Ask HN: What's your favorite way of getting a web app up quickly in 2018?

Showing the 15 most recent of 25 sources. Enable JavaScript to search and browse every indexed mention.

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.