Toasty, an async ORM for Rust

Original Article ↗ Hacker News Discussion ↗

A new async ORM for Rust called Toasty is prompting comparisons to existing tools like Diesel, SeaORM, SQLx, and Prisma-style systems, with many welcoming its compile-time safety, code generation, and Django/Prisma-like developer experience. Commenters are split over ORMs in general: some value faster development, type-safe query building, and automatic migrations, while others argue raw SQL or lighter query builders are more transparent, composable, and easier to optimize at scale. The project’s custom schema DSL and tight integration with Rust’s async ecosystem are seen both as powerful advances and as sources of added complexity.

Positioning vs Existing Rust DB Tools

  • Many compare Toasty to Diesel, SeaORM, SQLx, and Prisma-style tools.
  • Some see it as a middle ground: Diesel-like compile‑time checking with a more ergonomic query builder like SeaORM.
  • Diesel’s strong typing and lack of built‑in async lead some to prefer SQLx; diesel_async exists but is reported as harder to integrate with pooling than SQLx.
  • SeaORM is described by some as too opinionated, especially around migrations.
  • A few say existing options are “already solid” and remain happy with Diesel + diesel_async, SQLx, or SeaORM for now.

Schema & Code Generation Approach

  • Toasty’s custom .toasty schema file divides opinion.
  • Critics prefer defining models in Rust and using proc-macros, highlighting lost LSP tooling, refactors, and “inventing a new language.”
  • Supporters liken it to Prisma: a DSL as schema source-of-truth that auto-generates types, models, and migrations, reducing schema drift.
  • There is exploration of achieving similar guarantees using only Rust structs + macros as a counter-approach.

Async Design & Rust Ecosystem

  • Some ask why an ORM must care about async; others answer that ORM field access often triggers I/O and must not block event loops.
  • Discussion notes Diesel itself is sync-only, with async provided by a separate crate.
  • One thread examines Rust async’s friction and its incompatibility with non-async code in practice, despite technical interop tools like spawn_blocking / block_on.

ORM vs Raw SQL / Query Builders

  • Strong anti-ORM sentiment surfaces: ORMs are seen as leaky abstractions, bad fits for relational models, hard to optimize (N+1, unexpected queries), and producing awkward schemas.
  • Pro-ORM voices argue most queries are simple, productivity and type safety outweigh downsides, and escape hatches for raw SQL handle edge cases.
  • Some argue that “just mapping queries to structs” is effectively a minimal, homegrown ORM; others push back that this is only an I/O layer, not full ORM.
  • SQLx is praised for static checking on fixed queries but criticized for weak support for dynamic queries; some want better query builders.
  • A subthread debates SQL compositionality versus query-builder composition (views/CTEs vs method-chained builders), with no consensus.

Performance, N+1, and Complexity

  • Several report painful experiences where ORMs caused severe N+1 or N*k query patterns and long page load times, requiring later rewrites in raw SQL or query builders.
  • Others counter that N+1 issues usually stem from misuse, lack of documentation reading, or specific frameworks, not ORMs in general.
  • Consensus: good ORMs should make it easy to preempt N+1 and allow selective raw SQL for complex or performance-critical paths.

NoSQL and Custom ORMs

  • One perspective: for NoSQL systems (e.g., single-table patterns, fully denormalized data), writing a custom ORM or “OM” can fit the data model well.
  • Counterpoint: building your own ORM is usually a poor investment; better to avoid unless requirements are very specific.

Rust Productivity, Culture & Naming

  • Some highlight the article’s argument that Rust is productive over a project’s lifetime (fewer bugs, better reuse) despite slower edit-compile cycles.
  • There’s a view that Rust’s culture of correctness and maintainability, not just memory safety, makes it attractive even for web apps.
  • A minor thread laments whimsical crate names like “Toasty” as uninformative compared to more descriptive naming traditions.