SQLite Table Generator
Design a table for SQLite and get SQL that respects how SQLite really works: INTEGER PRIMARY KEY as the auto-incrementing rowid, STRICT tables that enforce column types, CHECK constraints so booleans stay 0 or 1 and enum columns hold allowed values, foreign keys together with the PRAGMA that turns them on, and a trigger that maintains updated_at.
- Runs in your browser
- No sign-up
- Free to use
How to use SQLite Table Generator
- Enter the table name and add the columns.
- Choose STRICT, WITHOUT ROWID and AUTOINCREMENT options.
- Add timestamps, soft delete and indexes.
- Copy the SQL into your app or migration.
SQLite Table Generator features
SQLite types
INTEGER, REAL, TEXT and BLOB, with CHECKs for booleans and enums.
STRICT tables
Type enforcement from SQLite 3.37.
Row ids
INTEGER PRIMARY KEY, optional AUTOINCREMENT and WITHOUT ROWID.
Foreign keys
Constraints plus PRAGMA foreign_keys = ON.
updated_at trigger
Keeps the timestamp current on every update.
Explained
Notes on how SQLite stores dates, booleans and JSON.
When to use SQLite Table Generator
- Designing local databases for mobile and desktop apps.
- Creating tables for Python, Node.js or PHP scripts.
- Prototyping a schema before moving to a server database.
- Learning SQLite’s type system.
SQLite Table Generator FAQ
Why do foreign keys need a PRAGMA?
For backwards compatibility SQLite ignores foreign key constraints unless PRAGMA foreign_keys = ON is executed on each connection.
What do STRICT tables do?
Normally SQLite stores any value in any column. In a STRICT table, values must match the column type (INTEGER, REAL, TEXT, BLOB or ANY), which catches bugs early. It needs SQLite 3.37 or later.
Should I use AUTOINCREMENT?
Usually not. INTEGER PRIMARY KEY already assigns new ids; AUTOINCREMENT only guarantees that ids of deleted rows are never reused, at a small cost.
When is WITHOUT ROWID useful?
For tables with a non-integer primary key, such as key-value settings, it saves space and a lookup.
How are dates stored?
As ISO 8601 text such as 2026-03-14 09:30:00, which sorts correctly and works with SQLite’s date functions.
Is anything uploaded?
No. The SQL is generated in your browser.
Designing for SQLite
SQLite is different from server databases in ways that matter for table design. Its columns have type affinity rather than strict types, foreign keys are off unless you enable them, dates have no dedicated type, and the rowid gives every ordinary table a hidden integer key. The generator writes SQL that works with these rules instead of against them.
Types are mapped to SQLite’s storage classes: integers and booleans to INTEGER, floating-point numbers to REAL, text, dates and JSON to TEXT and binary data to BLOB. Booleans get CHECK (column IN (0, 1)) and enum columns a CHECK listing their values, so invalid data is rejected. With the STRICT option, SQLite also enforces the declared types themselves.
An auto-increment id becomes INTEGER PRIMARY KEY, which is an alias for the rowid and therefore the fastest key SQLite has. AUTOINCREMENT can be added when ids must never be reused. Tables keyed by text, such as settings, can be declared WITHOUT ROWID to store rows in primary-key order without the hidden rowid.
Foreign keys are written as constraints, and the script starts with PRAGMA foreign_keys = ON, which every connection needs before SQLite enforces them. Many surprises with SQLite come from forgetting this pragma.
SQLite has no ON UPDATE clause, so the timestamps option adds an AFTER UPDATE trigger that sets updated_at to CURRENT_TIMESTAMP when a row changes, guarded so that it does not trigger itself repeatedly.