HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
transact-rs
sqlx
Rust2019–2026
transact-rs / sqlx

sqlx

🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, and SQLite.

Data & DatabasesSystems & Infrastructure
Explore on GitHubRead Hacker News discussions
42Distinct people
48Mentions
1Explicit recommenders
17.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, and SQLite.

GitHub

Where it is used

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

What people are saying

Also look at https://github.com/launchbadge/sqlx. I love compile-time checked queries (it's optional). It's simple to use too, async and includes a pool.

brunoqc used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

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, 11:00:58 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 year48 dated mentions

Observed mentions: 2019-12-30 07:15:03 UTC to 2026-06-04 10:34:25 UTC.

0510152019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 5 mentions; 2 submissions, 3 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 14 mentions; 1 submissions, 13 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

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
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC110
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC523
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC505
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC707
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC14113
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC716
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC615
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC303

What Hacker News says

3 sources
ninkendo¡Jun 4, 2026
> Otherwise you would have known that the defaults you're complaining about are clearly identified in the README files you didn't read. None of what you’re saying about my scenario is true at all. You’re hallucinating shit worse than LLM’s. There was no README that outlined the behavior. There was no change log entry. The sqlx crate did not document a single thing related to this at all. You’re missing critical information and making enormous assumptions, and jumping to attacking my character as the very first step. Maybe you googled just enough about the sqlx and whoami crates to come to a wrong conclusion. Because there was a changelog entry related to whoami in the sqlx release notes. And yes I read it. But guess what: that wasn’t the issue. The issue is a legitimate bug in sqlx related to how they use the whoami crate. There’s no clea
Read the rest
rly identified README entry. There’s just a sqlx bug in 0.9. I’d explain in detail exactly what the bug is but you’re not interested because you’ve already made your conclusion about me before you have any information about what happened. (Hint: the whoami crate decided to move the functionality that actually grabs your username behind the `std` crate feature, and made the std feature enabled by default. But the sqlx crate has always included whoami with `default_features = false`. I’ll leave you to guess what happened as a result. Before you answer, you should also learn how cargo treats crate features in a build where the whoami crate is linked multiple times with different features. Once you think you have it figured out, go and find this README entry I should have read.) Edit: actually, fuck it, I’m sick of being coy. Here’s the sqlx regression: https://github.com/transact-rs/sqlx/pull/4275 Note how it’s still open as of this writing. Note how it’s not “clearly stated in the README”. It’s a bug. A bug that’s still not fixed.
In Corporate America Is Starting to Ration AI as Cost Skyrockets
chrismorgan¡May 30, 2026
I don’t like strict tables, because it conflates two concerns, with one somewhat good and one distinctly bad effect (in my assessments). The somewhat good: it gets rid of most of the weak typing. It still coerces, in line with other SQL databases, but at least a column will only store values of one type. Personally I’d prefer to opt out of the coercion. And I don’t think most ways of writing SQL (in applications especially, but also manually) will ever actually trigger the strict differences. So it doesn’t feel like it’s actually particularly useful. The distinctly bad: you’re limited to six datatype names. You may well now want external documentation or load-bearing comments in your schema, and your application code may be hobbled, if it liked to infer types based on the datatype name. For example, in sqlx, SQLite datatype BOOLEAN can au
Read the rest
tomatically map to Rust type bool <https://github.com/transact-rs/sqlx/blob/75bc0487eb661da811b...>. Without that, you have to resort to a variety of less-pleasant techniques, such as selecting `done as "done: bool"` or overriding things in sqlx.toml. I really, really wish they’d implement some form of CREATE TYPE and let that work with strict tables. If I could `CREATE TYPE BOOLEAN FROM INTEGER` and such, I’d be all in on strict tables.
In SQLite is all you need for durable workflows

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.