Toasty, an async ORM for Rust

Original Article ↗ Hacker News Discussion ↗

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.