This tool supports MySQL/MariaDB, PostgreSQL, SQLite, SQL Server, and Oracle. Each database has slightly different syntax — for example, auto-increment is AUTO_INCREMENT in MySQL, SERIAL in PostgreSQL, IDENTITY(1,1) in SQL Server, and GENERATED BY DEFAULT AS IDENTITY in Oracle. Choosing the correct dialect ensures your SQL runs without errors on your target database.

PRIMARY KEY uniquely identifies each row and automatically implies NOT NULL + UNIQUE. Each table can have only one primary key. UNIQUE ensures all values in a column are distinct but allows NULL values (in most databases). INDEX speeds up searches on a column without enforcing uniqueness — ideal for columns frequently used in WHERE clauses like email or username lookups.

Use VARCHAR(n) when you know the maximum length (e.g., names, emails, zip codes) and want to enforce a limit. VARCHAR is stored inline with the row and is faster for shorter strings. Use TEXT for unbounded or very long content (e.g., blog posts, descriptions, JSON blobs) — it's stored separately and has no practical length limit. VARCHAR is generally preferred for indexed columns.

NULL means the column can have no value (unknown/missing). NOT NULL enforces that every row must have a value for that column. Best practice: use NOT NULL for required fields (like email, username) and allow NULL only for optional data (like middle name, avatar URL). NOT NULL columns can improve query performance and prevent accidental missing data.

Copy the SQL or download the .sql file, then run it in your database client (like MySQL Workbench, pgAdmin, DBeaver, or the command line). For MySQL: mysql -u root -p database_name < file.sql. For PostgreSQL: psql -U postgres -d database_name -f file.sql. Always test on a development database first before running on production.

This tool focuses on single-table schema design. Foreign keys reference columns in other tables, which requires those tables to exist first. After generating your base tables, you can manually add FOREIGN KEY (column) REFERENCES other_table(id) constraints using ALTER TABLE statements. We recommend designing all your tables first, then adding foreign keys in a separate migration step.

Use snake_case (e.g., user_orders) for maximum compatibility across databases. Table names should be plural nouns (users, products). Column names should be descriptive but concise. Avoid reserved keywords (like order, group, select) as column names. Use consistent naming — if you use created_at in one table, don't use create_date in another.