TheDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/tailor-platform/sdk/llms.txt
Use this file to discover all available pages before exploring further.
tailordb migration commands help you manage database schema changes safely with automatic diff detection, migration file generation, and data transformation scripts.
Overview
The migration system detects field-level schema differences between your local type definitions and the previous snapshot, then generates migration files to safely apply those changes.Key Features
- Local snapshot-based diff detection - Compares current types with previous migration snapshot
- Transaction-wrapped data migrations - All changes commit or rollback together for atomicity
- Automatic execution during apply - Pending migrations run as part of
tailor-sdk apply - TypeScript migration scripts - Type-safe data transformations using Kysely
Commands
tailordb migration generate
Generate migration files by detecting schema differences between current local types and the previous migration snapshot.Options
Path to SDK config file
Optional description for the migration (e.g., “add email field to user”)
Skip confirmation prompts
Delete existing migrations and start fresh (requires confirmation)
Generated Files
Each migration creates a directory with a 4-digit sequential number:| File | Description |
|---|---|
0000/schema.json | Initial schema snapshot (first migration only) |
XXXX/diff.json | Schema diff from previous snapshot |
XXXX/migrate.ts | Data migration script (only for breaking changes) |
XXXX/db.ts | Generated Kysely types for the migration script |
Migration Script Structure
db.ts file contains Kysely types reflecting the schema before the migration runs, ensuring type-safe transformations.
Editor Integration
If theEDITOR environment variable is set, the generated script opens automatically:
Examples
tailordb migration set
Set migration checkpoint to a specific number.Arguments
Migration number to set (e.g.,
0001 or 1)Options
Workspace ID for the operation
Workspace profile to use
Path to SDK config file
Target TailorDB namespace (required if multiple namespaces exist)
Skip confirmation prompts
Examples
tailordb migration status
Show the current migration status for TailorDB namespaces, including applied and pending migrations.Options
Workspace ID for the operation
Workspace profile to use
Path to SDK config file
Target TailorDB namespace (shows all namespaces if not specified)
Example Output
Examples
Configuration
Configure migrations intailor.config.ts:
Configuration Options
| Option | Type | Description |
|---|---|---|
files | string[] | Glob patterns for TailorDB type definition files |
ignores | string[] | Glob patterns to ignore |
migration.directory | string | Directory path for migration files |
migration.machineUser | string | Machine user name for migration script execution (optional) |
Machine User Selection
When executing migration scripts, the system selects a machine user in the following priority:- Explicit configuration:
migration.machineUserin db config - Auto-selection: First machine user from
auth.machineUsers
Migration Directory Structure
Automatic Migration Execution
When runningtailor-sdk apply, pending migration scripts are automatically executed as part of the deployment process.
How It Works
- Pending Migration Detection: Identifies migration scripts that haven’t been executed yet
- Two-Stage Type Update: For breaking changes:
- Pre-Migration: New fields are added as
optionalfirst - Script Execution: Migration scripts run to populate data
- Post-Migration: Fields are changed to
required, deletions are applied
- Pre-Migration: New fields are added as
Execution Flow
Requirements
- Migrations configured:
migrationpath set in db config - Auth configured: Auth service with machine users
- Kysely generator:
@tailor-platform/kysely-typegenerator configured
Example Output
Schema Verification
By default,tailor-sdk apply performs two schema verifications:
- Local schema check: Ensures local type definitions match the migration snapshot
- Remote schema check: Ensures remote schema matches the expected state
Skipping Schema Check
Supported Schema Changes
| Change Type | Breaking? | Migration Script | Notes |
|---|---|---|---|
| Add optional field | No | No | Schema change only |
| Add required field | Yes | Yes | Script populates default values |
| Remove field | No | No | Schema change only - data is preserved |
| Change optional→required | Yes | Yes | Script sets defaults for null values |
| Change required→optional | No | No | Schema change only |
| Add index | No | No | Schema change only |
| Remove index | No | No | Schema change only |
| Add unique constraint | Yes | Yes | Script must resolve duplicate values |
| Remove unique constraint | No | No | Schema change only |
| Add enum value | No | No | Schema change only |
| Remove enum value | Yes | Yes | Script migrates records with removed values |
| Add type | No | No | Schema change only |
| Remove type | No | No | Schema change only - data is preserved |
| Change field type | - | - | Not supported - requires 3-step migration |
| Change array property | - | - | Not supported - requires 3-step migration |
| Change foreign key relationship | Yes | Yes | Script updates existing references |
Unsupported Schema Changes
The following changes require a 3-step migration process:Field Type Change
Field type changes (e.g.,string → integer) are not directly supported. Use this strategy:
- Migration 1: Add a new field with the desired type (e.g.,
fieldName_new) and migrate data - Migration 2: Remove the old field
- Migration 3: Add the field with the original name and new type, migrate data from temporary field, then remove temporary field
Array Property Change
Changing between single value and array (e.g.,array: false → array: true) requires the same 3-step migration strategy.
Example Workflow
1. Modify your type definition
2. Generate migration
3. Edit the migration script
4. Apply migration
Troubleshooting
Remote schema drift detected
Cause: The remote schema doesn’t match the expected state based on migration history. Solution:- Check migration status:
tailor-sdk tailordb migration status - Sync with team: Ensure all team members have the same migration files
- Reset if needed:
tailor-sdk tailordb migration set <number> - Force apply (use with caution):
tailor-sdk apply --no-schema-check
Machine user not found
Cause: Specified machine user doesn’t exist in auth configuration. Solution:- Add machine user to your auth config:
- Run
tailor-sdk applyto deploy the auth config - Retry migration
Migration script execution fails
Cause: Runtime error in your data migration logic. Solution:- Check the error message for the failing query/operation
- Test your script logic locally if possible
- Fix the script
- Apply again:
tailor-sdk apply
See Also
- apply - Deploy application with automatic migration execution
- tailordb truncate - Clear table data