Skip to main content
Build a user service with create, list, fetch, update and delete endpoints. Run the checked-in example from a source checkout matching these docs; setup instructions explain the prerequisites.
20 minutesAxum → validated model → SQLite → JSON

1. Follow one model through the service

The User model derives both Model and SqlModel. The first supplies parsing and output validation. The second supplies SQL metadata, migrations and CRUD operations. name is trimmed, length-checked and unique. age must be between 18 and 120. SQLite supplies an ID when id is omitted. User::migrate(&pool) creates the table before the HTTP listener starts.
crates/rydantic/examples/sqlite_api.rs
The request extractor Json<User> validates before create executes. The handler calls insert and returns the stored row. That response is validated again by Rydantic’s Json adapter.

2. Run the in-process check

Expected output:
The smoke mode exercises a real Axum request and an in-memory SQLite database, then exits. It opens no listening socket.

3. Start the server

Keep that terminal running. The default address is http://127.0.0.1:3000, backed by a fresh in-memory database. In another terminal, create a user:
Expect 201 Created and a normalized row. On a fresh database it is:

4. Reject invalid input

Expect 422 Unprocessable Entity, with errors at name and age in the detail array. No row is inserted. Check the list:
It still contains only Ada. Posting Ada again returns 409 Conflict because the database enforces the unique name. Fetching a missing ID returns 404 Not Found.

5. Update and delete a row

Use the ID returned by the create request. For ID 1:
The update returns the changed row, deletion returns 204 No Content, and the final fetch returns 404. Stop the demo server with Ctrl-C.

6. Keep data between restarts

Choose a new local database file:
The model is migrated at startup. Subsequent runs reuse the file. The demo accepts loopback listen addresses and has no authentication; use it for local learning. To see a table evolve, run the migration example in its own in-memory database:
It creates an old Account, inserts a row, previews a rename and two added fields, then applies the plan. Assertions check that the old name survives, enabled is backfilled, and a second migration has no work.
crates/rydantic/examples/automatic_migrations.rs
Inspect plans and validate upgrades on a copy before using automatic migrations with application data. The migration guide documents supported changes and database-specific behavior.

Next: build a typed agent

Apply a Rust contract to an AI result.

Use PostgreSQL or MySQL

Run the same API with an independent SQL driver.