No Code Database

Database setup has traditionally been one of the biggest hurdles in application development. Choosing between PostgreSQL, MySQL, MongoDB, or dozens of other options requires expertise most builders do not have. Even after selecting a database, you face schema design, connection management, migration tooling, and hosting decisions. Fabricate eliminates this entire category of complexity by including a managed database with every application.

Fabricate uses the SQLite database built into Cloudflare Durable Objects. Every app gets one Durable Object, and its data lives in that object's storage, right next to the server code that reads and writes it. When you describe your application's data needs in natural language, the AI creates the tables, columns, indexes, and relationships between entities in that database.

The database panel built into the Fabricate studio shows your app's tables in two views: a data tab with the rows your app has stored, and a schema tab with the columns and types. It is read-only by design, so browsing your data can never change it; changes go through your app or through a request to the AI.

Schema changes follow the same conversational path. When you ask the AI to add new fields, create new tables, or modify relationships, it updates the server code that creates and alters those tables, so the schema always matches the code that uses it. There are no separate migration files to track or apply.

Security is enforced in your app's server code. The database is never reachable from the browser directly; clients only see what your routes return. When you add user accounts, the generated routes scope queries so users can only access their own data. Admin roles get broader access as defined by your application's permission model.

Every Fabricate app is backed by a single Cloudflare Durable Object, and that object carries its own SQLite database, accessed from the app's server code through ctx.storage.sql. There is nothing to provision: the database exists as soon as the app does, and it lives with the code that uses it, so queries do not cross the network to a separate database service.

The AI writes table definitions and queries in plain TypeScript inside the app's server (src/index.ts). No ORM or code generator sits between your code and the database, and query results are typed where they are used, so the shape of a row is visible in the same file that reads it.

Schema changes are part of the server code rather than a separate migration system. When you ask for a new field or table, the AI updates the statements that create and alter tables. There are no migration files to version or apply by hand.

The studio database panel reads your tables through read-only inspector endpoints and shows a data tab and a schema tab. It has no SQL editor on purpose: browsing your data cannot modify it.