Toasty generates only the operations a backend can support
Toasty starts with Rust structs marked by #[derive(toasty::Model)]. Field annotations identify keys, generated values, indexes, unique values, and relationships. The macro then creates typed insert and lookup methods. Registering those models gives Toasty enough information to infer tables, indexes, and relations, while Db::builder() connects that model set to a selected driver.
The unusual part is its refusal to flatten every database into one pretend dialect. A SQL driver can allow extra query constraints, while DynamoDB methods are generated around indexed access patterns and sort keys. That can prevent a convenient-looking query from becoming an accidental scan. It also means changing backends can change which methods exist, so portability depends on using the common capability set your application has actually tested.
Version 0.11 covers 6 connection schemes with different behavior
The current database guide documents SQLite, Turso, PostgreSQL, MySQL, MariaDB, and DynamoDB connection schemes. MariaDB support arrived in v0.11 with native UUID columns and INSERT ... RETURNING. A mysql:// URL aimed at the same MariaDB server deliberately keeps MySQL behavior, including different UUID storage. Switching the URL scheme can therefore require a schema migration.
Turso also has two modes. A local path or :memory: uses the embedded engine, while a hosted URL selects the serverless HTTP driver and accepts a token. DynamoDB draws credentials and region details from AWS configuration. Toasty gives these backends a shared model vocabulary, but deployment still requires per-driver TLS, credentials, connection limits, and failure testing.
What happened when we ran it
Our sandbox installed 216 packages in 25 seconds. The full source build succeeded after 279 seconds on 3 CPUs with 12 GB of RAM. This was a sizeable checkout: 1,115 files, about 171,307 source lines, and 6.6 MB before dependencies. Six CI workflow files, a compose file, and a tests directory were present.
The test step did not pass. After 274 seconds, cargo test exited 101 while rustc was compiling toasty-driver-integration-suite. The tail also showed example and fixture crates compiling, followed by a message that other jobs were still finishing. It did not contain the actual compiler diagnostic. Our result supports only the narrow finding that commit 6a1f5d9 built with the lab's build command but failed during test compilation in that fresh container.
That distinction matters for a database library. The repository clearly contains substantial test code and driver-specific CI, yet our default run still failed before producing a test count. A prospective adopter should run the same feature combination, database services, and toolchain intended for production. We would not turn this log into a theory about memory, system packages, or a particular driver because the supplied tail does not show one.
Migrations work, but your application supplies the CLI binary
For prototypes, push_schema() creates tables and indexes directly from registered models. Production use has a migration system that compares current models with a stored snapshot, writes database-specific SQL, and records applied IDs in a __toasty_migrations table. Generated migrations can also be embedded in a compiled application.
There is an extra setup step: Toasty cannot ship a universal standalone generator because migration code needs access to your model types. The guide asks each project to add toasty-cli, create a small binary that registers its models, and keep a Toasty.toml plus migration history. This is defensible Rust architecture, though it is more ceremony than running a global CLI against a schema file. Generated SQL still deserves review before it touches data.
The roadmap names missing query and relationship features
Toasty's roadmap is unusually honest about commitment. It says an entry means maintainers agree the feature should exist, not that work is scheduled, assigned, or imminent. Current entries include many-to-many relations, relation filtering, aggregates, upsert, manual SQL transactions, row locking, full-text search, and several advanced PostgreSQL index types.
Those are normal application requirements, not decorative extras. Issue 1246, for example, reports no method for filtering parents whose optional has_one relation is absent in v0.10. Open engine work in September also covered null semantics and unsupported filter paths. Before choosing Toasty, model 5 or 10 of your hardest real queries and confirm they compile and produce acceptable database operations. A successful quickstart cannot answer that question.
v0.11 activity is high and upgrade work is real
GitHub recorded a push on September 26, 2026, hours after Toasty v0.11.0 was released on September 25. The project had 3,158 stars and 106 open issues and pull requests. Recent changes included relation work, MariaDB, Turso serverless support, dependency updates, documentation, and fixes across the engine. This is active development rather than a dormant experiment.
The release also carries several breaking changes. Newtype accessors were renamed, one enum-backed column pattern changed and needs migration, Turso serverless behavior changed, and MySQL now rejects bulk inserts that depend on inferred auto-increment IDs. That is reasonable movement for a 0.x ORM, but it sets the buyer profile. Toasty fits a new Rust service whose team wants database-aware generated APIs and can absorb change. SeaORM and Diesel offer SQL-oriented ORM alternatives, while SQLx is the cleaner choice when explicit SQL is part of the design.