Safe relational database queries using the Rust type system

Original Article ↗ Hacker News Discussion ↗

A new Rust library, rust-query, aims to provide fully type-safe, compile‑time‑checked database access by owning both schema definition and migrations, prompting comparisons with existing tools like Diesel, SQLx, and SeaORM. Commenters debate the trade‑offs between code‑first vs. database‑first schemas, compile‑time guarantees vs. the realities of evolving production databases and zero‑downtime deployments, and whether higher‑level ORMs can ever beat writing SQL directly for flexibility and performance. The thread also surfaces broader concerns about SQL’s ergonomics, dynamic query building, async I/O in Rust, and how much control applications should have over database schema and query planning.

Rust database ecosystem and compile-time safety

  • Many welcome more experimentation in Rust DB libraries, but note existing options (Diesel, SQLx, SeaORM/SeaQuery, Prisma).
  • Diesel and SQLx are repeatedly cited as already providing strong compile-time guarantees; Diesel’s are considered stricter, especially for dynamic queries.
  • SeaORM is praised as a well-designed, pleasant ORM but criticized by some for lacking compile-time query safety.
  • There is debate over whether compile-time validation is essential for an ORM, especially once queries become dynamic.

SQL vs ORMs vs query builders

  • Several commenters strongly prefer writing SQL directly, arguing it is already a high-level, widely understood language with excellent tooling and docs.
  • Others find SQL awkward, inconsistent, and hard to optimize or debug, and like higher-level abstractions (ORMs, LINQ/jOOQ-style builders).
  • SQLx is highlighted as a good “middle ground”: write SQL, get type-checked parameters and result mapping, but it struggles with highly dynamic queries.
  • Some argue ORMs stack one high-level abstraction on top of another (SQL), making performance tuning and understanding actual queries harder.

Dynamic query construction

  • Pattern of using NULL checks / CASE expressions to simulate optional filters is discussed; seen as useful but insufficient for complex dynamic APIs (dynamic columns, operations, IN lists, dynamic UPDATE/INSERT sets).
  • Concern that lack of robust, type-safe dynamic query support pushes teams towards manual string concatenation and potential SQL injection.

Schema authority, migrations, and rust-query’s model

  • Big debate over whether application-defined schema (as in rust-query) is “authoritative” vs the database itself.
  • rust-query runs migrations, reads schema, and panics if DB schema diverges; it also checks SQLite’s schema_version per transaction.
  • Operators with large-scale experience argue this is brittle:
    • Real systems need hot fixes, manual indexes, online schema changes, zero-downtime and blue/green deploys, multiple app instances, and sometimes DB-level tools.
    • Requiring exact schema equality can make these workflows impossible or force downtime.
  • Alternatives proposed: treating the DB as a separate service with a stable interface, runtime schema/version checks, or looser compatibility rather than exact matches.

Other design and performance concerns

  • Row-by-row migrations are seen as potentially disastrous on very large tables.
  • Hiding internal row numbers (rowid) is defended for safety; public identifiers should use separate keys.
  • Some see rust-query (and similar efforts) as promising exploration; others view it as a toy not yet shaped by “battle-hardened” production experience.