The embed_schema! macro reads your database/schema/ directory at compile time and generates a Rust module containing the SQL for every .surql file it finds. Because the schema is compiled into the binary, there are no external files to deploy and the schema version is always tied to the application version.
Add SurrealKit to your dependencies. The embed_schema! macro is re-exported from the main crate, so a single dependency is enough:
Basic usage
Call the macro at the crate root (typically main.rs or lib.rs):
This generates an embedded_schema module. Call sync on it after connecting to apply any outstanding schema changes:
sync behaves identically to surrealkit sync from the CLI: it applies new or changed definitions and prunes any that have been removed, using the __entity metadata table to track state.
What the macro generates
Given a database/schema/ directory with these files:
The macro generates roughly:
The generated SCHEMA static is public, so when you need to customise sync behaviour you can pass it to the Sync builder directly instead of calling embedded_schema::sync:
Compile-time rebuild behaviour
Cargo re-runs the macro whenever a .surql file in database/schema/ changes, because the macro registers each file with include_str!. This means schema changes always produce a fresh build, and there is no risk of shipping stale SQL.
When to use the macro vs runtime loading
| - | embed_schema! | Runtime Sync |
|---|---|---|
| Schema location | Compiled into binary | Built from files at runtime |
| Deployment | No schema files needed | Schema directory must be present |
| Dev iteration | Rebuild required on change | Files can be swapped without rebuild |
| Best for | Production builds, Docker images | Development, mounted volumes |
For most production deployments embed_schema! is the right choice. For local development or environments that mount schema as a volume, building an EmbeddedSchemaFile slice at runtime and passing it to Sync::embedded is more convenient.