Very interested in exploring how this will compare to Diesel [1] and SeaORM [2], the other two options in this space today. Joshua Mo at Shuttle did a comparison between Diesel and SeaORM in January of this year that was really interesting [3].
My first reaction is this feels like a nice middleground between Diesel and SeaORM.
The codegen part makes all columns and tables and stuff checked at compile-time (name and type) like Diesel, with a query builder that's more natural like SeaORM. I hope the query builder does not end up too magical like SQLAlchemy with its load of footguns, and stay close in spirit to Diesel that's "write sql in rust syntax".
I think time will tell, and for now I'm keeping my Diesel in production :D
Sea ORM is too opinionated in my experience. Even making migration is not trivial with their own DSL.
Diesel was ok, but I never use it anymore since rocket moved to async.
I'm mainly use sqlx, it's simple to use, there's query! and query_as! macro which is good enough for most of the case.
I use SQLx, but I'm not totally convinced it's better than writing raw SQL with the underlying postgres/sqlite3/mysql driver. The macros and typing fall apart as soon as you need anything more complicated than basic a SELECT with one to one relationships, much less one/many to many.
I remember fighting with handling enums in relations for a while, and now just default to manually mapping everything.
SQLx can handle complicated queries as long as they're completely static strings. We've got SELECT FOR UPDATE, upserts, and some crazy hundred-line queries that are fine with their macros.
SQLx sucks at dynamic queries. Dynamic predicates, WHERE IN clauses, etc.
For SQLx to be much more useful, their static type checker needs to figure out how to work against these. And it needs a better query builder DSL.
Right, it's not bad if you stick with what the type checker can handle, but I usually end up falling back on manual building with the majority of queries in any semi-complex app.
It doesn't end up being too bad though, except for the loss of compile time syntax checking. Manually handling joins can be kind of nice, it's easier to see optimizations when everything is explicit.
It's nice seeing more Django/Prisma style ORMs where the non-SQL source code is the source of truth for the schema and migrations are automatically generated.
[1]: https://diesel.rs/
[2]: https://www.sea-ql.org/SeaORM/
[3]: https://www.shuttle.dev/blog/2024/01/16/best-orm-rust