Limitations

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