> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bytebase.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 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)
```sql theme={null}
-- Required: public.users
-- Not allowed: users
```
2. **PRIMARY KEY, UNIQUE, FOREIGN KEY, CHECK must be table-level with explicit names**
```sql theme={null}
-- Correct:
CONSTRAINT users_pkey PRIMARY KEY (id)
-- Not allowed:
id INTEGER PRIMARY KEY
```
3. **Only NOT NULL, DEFAULT, GENERATED allowed at column level**
```sql theme={null}
-- 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**
```sql theme={null}
-- Required:
REFERENCES public.users(id)
-- Not allowed:
REFERENCES users(id)
```
5. **All indexes must have explicit names**
```sql theme={null}
-- 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:
```sql theme={null}
-- 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)
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
Learn about the imperative alternative
{' '}
Production-ready workflow patterns
{' '}
Solutions for common issues
Return to GitOps overview