Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
sqlx
🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, and SQLite. (by launchbadge)
-
Prisma Client Rust. If you come from the JS/TS world this fits right in. It's halfway between a full ORM and SQL(x), so I prefer it.
No it will likely not be less performant. See these numbers for some benchmark results for numbers. (As always with benchmarks: Please don't trust my numbers. To be sure you need to do your own benchmarks with your own use-case)
I like Cornucopia. It’s a SQL-first approach, so I don’t have to worry about an ORM generating pathological queries. It’s also basically zero cost compared to directly using rust-postgres and supports both sync and async. I also like that my SQL queries end up separate from my Rust code, so it’s easy to update all the relevant queries when the schema changes.
None. I find ORMs to be too restrictive when I really need to get in and optimize my queries. I wrote my own custom query builder which allows me to use mixed SQL/Rust syntax for complex dynamic queries.
however, a much worse problem is its inability to do dynamic queries. If you have two queries that only differ in a column name, you're forced to copy paste the entire query. You can try and hack around it, but it's ugly either way. Here's a good overview, with no really good solutions.
some things are barely expressible in the type system. For example, window functions are unavailable (the issue is six years old). You can use raw SQL, but then it has the same problems sqlx has