Database

Every Fabricate app comes with its own database: the SQLite storage built into the app’s Cloudflare Durable Object. It requires zero configuration from you.

How It Works

When you build an app with Fabricate, the AI automatically:

Designs your tables based on what your app needs
Writes the code that creates them — your app’s server creates its tables when it runs
Writes database queries in your API routes
Updates your tables when you add new features that need new tables or columns

You don’t write SQL. You describe what you need and the AI handles the database.

Your preview and your published app have separate databases. Data you create while testing in the preview isn’t copied when you publish, and a newly published app starts with an empty database.

Example

Prompt: "Add a comments system to the blog. Each comment should have the 
         author's name, email, content, and timestamp."

Fabricate will:

Add a comments table to your app’s database code
Make sure the table is created when your app runs, including in apps that already have data
Add API routes to create, read, and delete comments
Update the frontend to display comments on blog posts

Schema Example

A typical Fabricate app’s own tables might look like:

CREATE TABLE IF NOT EXISTS projects (
  id TEXT PRIMARY KEY,
  user_id TEXT NOT NULL,
  name TEXT NOT NULL,
  description TEXT,
  created_at INTEGER NOT NULL
);

When your app has accounts, Fabricate’s built-in sign-in keeps users and sessions in its own tables (such as fabricate_auth_users and fabricate_auth_sessions), and your app’s tables store the signed-in user’s id with each row.

Data Access

Your app’s API routes read and write data through the Durable Object’s SQL storage. Fabricate generates these routes for you. Example:

if (url.pathname === "/api/projects" && request.method === "GET") {
  const user = await requireSessionUser(request, this.ctx, this.env); // from the built-in sign-in
  if (!user) return Response.json({ error: "Not signed in" }, { status: 401 });
  const projects = this.ctx.storage.sql.exec(
    "SELECT * FROM projects WHERE user_id = ? ORDER BY created_at DESC",
    user.id,
  ).toArray();
  return Response.json(projects);
}

Limitations

Your app’s database is SQLite, and every visitor to your published app uses the same database — that’s why apps that keep per-user records use accounts, so each person sees only their own rows. SQLite is great for most web apps, but it isn’t a fit if you need PostgreSQL-specific features or very high write throughput.

Frequently Asked Questions

Can I see my database data?

Yes, for the preview. Open the Database view in the workspace to browse your app’s tables and rows. It shows the preview’s data and is read-only, apart from an option to delete all preview data. There’s currently no view of your published app’s data.

Can I import existing data?

There’s no import tool. You can ask Fabricate to add sample data that your app creates when it runs, or to build an import feature into your app. Keep in mind that the preview and your published app have separate databases.

What happens to my data if I switch plans?

Your data stays in your app when you change plans. If you move to the Free plan, any private apps become public.

Can I add indexes for performance?

Yes. Ask Fabricate to add database indexes: “Add an index on the projects table for user_id to speed up user project queries.”

Overview

Editor

Tech Stack

Code & Export

Test and connect

How It Works

Example

Schema Example

Data Access

Limitations

Frequently Asked Questions

​How It Works

​Example

​Schema Example

​Data Access

​Limitations

​Frequently Asked Questions

How It Works

Example

Schema Example

Data Access

Limitations

Frequently Asked Questions