Skip to main content
State-based workflow (SDL) currently has these limitations:

​
Database Support

Supported:
  • PostgreSQL
Not yet supported:
  • MySQL
  • SQL Server
  • Oracle
  • MongoDB
  • Other databases

​
Supported SQL Statements

Only these PostgreSQL statements are supported:
  • CREATE TABLE
  • CREATE INDEX / CREATE UNIQUE INDEX
  • CREATE VIEW
  • CREATE SEQUENCE
  • CREATE FUNCTION
  • ALTER SEQUENCE (for OWNED BY)
Not supported:
  • Complex stored procedures
  • Triggers
  • Row-level security policies
  • DML operations (INSERT, UPDATE, DELETE)
  • Transaction control
  • Database-level settings

​
Strict Syntax Requirements

SDL requires strict adherence to conventions:
  1. All objects must use fully qualified names (with schema prefix) 
    -- Required: public.users
-- Not allowed: users
  2. PRIMARY KEY, UNIQUE, FOREIGN KEY, CHECK must be table-level with explicit names 
    -- Correct:
CONSTRAINT users_pkey PRIMARY KEY (id)

-- Not allowed:
id INTEGER PRIMARY KEY
  3. Only NOT NULL, DEFAULT, GENERATED allowed at column level 
    -- Allowed:
id SERIAL,
name TEXT NOT NULL,
created_at TIMESTAMP DEFAULT NOW()

-- Not allowed:
id INTEGER PRIMARY KEY
  4. Foreign key references must be fully qualified 
    -- Required:
REFERENCES public.users(id)

-- Not allowed:
REFERENCES users(id)
  5. All indexes must have explicit names 
    -- Required:
CREATE INDEX idx_users_email ON public.users(email)

-- Not allowed:
CREATE INDEX ON public.users(email)

​
No Direct Data Operations

SDL only manages schema structure. For data operations, use migration-based workflow. Not supported in SDL:
  • INSERT statements
  • UPDATE statements
  • DELETE statements
  • Data transformation logic
Solution: Combine both workflows: 
schema/               # SDL for schema structure
  ├── tables.sql
  └── indexes.sql
migrations/           # Migration-based for data
  ├── 001__seed_roles_dml.sql
  └── 002__migrate_users_dml.sql

​
Destructive Operations

SDL-generated DROP statements execute automatically when objects are removed from files: 
-- Remove table from SDL file
-- → Bytebase generates: DROP TABLE old_table;
Always backup data before deploying SDL changes that remove objects from schema files. Bytebase will automatically drop those objects.

​
Limited Rollback

SDL only moves forward to new desired states:
  • No automatic rollback generation
  • To rollback: revert SDL files to previous state and redeploy
  • Data in dropped objects is lost (backup required)

Schema Rollback Strategies

Approaches for reversing schema changes

​
Performance Considerations

For large schemas:
  • Initial SDL adoption requires exporting complete schema
  • State comparison time increases with schema complexity
  • DDL generation uses topological sort (handles dependencies)
Mitigation:
  • Organize schema into multiple files
  • Use database groups for fleet management
  • Test SDL workflow on staging first

​
Next Steps

Migration-Based Workflow

Learn about the imperative alternative

Best Practices

Production-ready workflow patterns

Troubleshooting

Solutions for common issues

GitOps Overview

Return to GitOps overview