Database

Store and query structured data with SQLite (default), Cloudflare D1, or Supabase. All backends use the same local: fetch syntax and form actions.

How Data Works

The What framework stores all collection data as JSON blobs inside database tables. Every backend uses the same schema:

-- Each collection (e.g., "posts") becomes a table:
id INTEGER PRIMARY KEY AUTOINCREMENT
data TEXT NOT NULL  -- JSON object with all fields

-- Key-value pairs use a system table:
_kv_store (key TEXT PRIMARY KEY, value TEXT)

This means your templates and forms work identically regardless of which backend you use. Switching backends is a config change, not a code change.

Default: SQLite (Zero Config)

With no [database] section in what.toml, What automatically creates a SQLite database at data/app.db. No configuration needed.

your-project/
  data/
    app.db            <!-- auto-created on first run -->
    sessions.db       <!-- separate file for sessions -->
  site/
  what.toml         <!-- no [database] section needed -->

SQLite is the default backend and works great for development and single-server deployments. Tables are created automatically the first time you write data — no configuration needed. Data persists across restarts but is not guaranteed to survive redeploys unless you explicitly preserve the data/ directory (via Docker volume mount or rsync exclude).

Querying Data

All data access goes through fetch directives with the local: prefix. You never write SQL directly.

<what>
fetch.posts = "local:posts"
fetch.posts.filter = "status=published"
fetch.posts.sort = "published_at:desc"
fetch.posts.limit = "20"
</what>

<loop data="#posts#" as="post">
  <article>
    <h2><a href="/blog/#post.id#">#post.title#</a></h2>
    <time>#post.published_at|date:"%B %d, %Y"#</time>
  </article>
</loop>

Create, update, and delete records through form actions:

<form w-action="create" w-store="posts">
  <input name="title" w-required>
  <textarea name="body"></textarea>
  <button type="submit">Create Post</button>
</form>

Data Persistence Across Redeploys

Understanding what survives a redeploy depends on your database backend and deployment method:

Cloudflare D1

D1 is Cloudflare's serverless SQL database. Your data lives on Cloudflare's edge network and survives all redeploys automatically.

Step 1: Create a D1 Database

1. Log in to the Cloudflare Dashboard
2. Go to Workers & Pages → D1 SQL Database
3. Click Create, name it (e.g., my-app-db)
4. Copy the Database ID (a UUID like a1b2c3d4-...)

Step 2: Get Your API Credentials

1. Go to My Profile → API Tokens (top right menu)
2. Click Create Token
3. Use the Edit Cloudflare D1 template, or create a custom token with:
   Account → D1 → Edit permission
4. Copy the API Token
5. Your Account ID is in the URL: dash.cloudflare.com/[ACCOUNT_ID]/...

Step 3: Create Tables in D1

In your D1 database console, run this SQL for each collection your app uses:

-- System tables (required once)
CREATE TABLE IF NOT EXISTS _kv_store (key TEXT PRIMARY KEY, value TEXT NOT NULL);
CREATE TABLE IF NOT EXISTS _collections (name TEXT PRIMARY KEY);

-- Create a collection table (repeat for each collection)
CREATE TABLE IF NOT EXISTS "posts" (id INTEGER PRIMARY KEY AUTOINCREMENT, data TEXT NOT NULL DEFAULT '{}');
INSERT OR IGNORE INTO _collections (name) VALUES ('posts');

Step 4: Configure what.toml

[database]
type = "d1"

[cloudflare]
account_id = "${CF_ACCOUNT_ID}"
api_token = "${CF_API_TOKEN}"
d1_database_id = "a1b2c3d4-e5f6-7890-abcd-ef1234567890"

Step 5: Set Environment Variables

Create a .env file (never commit this):

CF_ACCOUNT_ID=your-account-id-here
CF_API_TOKEN=your-api-token-here

Supabase

Supabase provides a hosted PostgreSQL database with a REST API. Your data is cloud-hosted and survives all redeploys automatically.

Step 1: Create a Supabase Project

1. Go to supabase.com and create an account
2. Click New Project, choose a name and region
3. Wait for the project to initialize (takes ~2 minutes)

Step 2: Get Your API Credentials

1. Go to Project Settings → API (left sidebar, gear icon)
2. Copy the Project URL (looks like https://xyzcompany.supabase.co)
3. Under Project API keys, copy the service_role key (the secret one, NOT the anon key)

Step 3: Create Tables in Supabase

Go to SQL Editor in your Supabase dashboard and run this for each collection:

-- System tables (required once)
CREATE TABLE IF NOT EXISTS _kv_store (key TEXT PRIMARY KEY, value TEXT NOT NULL);
CREATE TABLE IF NOT EXISTS _collections (name TEXT PRIMARY KEY);

-- Create a collection table (repeat for each collection)
CREATE TABLE IF NOT EXISTS "posts" (id BIGSERIAL PRIMARY KEY, data JSONB NOT NULL DEFAULT '{}');
INSERT INTO _collections (name) VALUES ('posts') ON CONFLICT DO NOTHING;

Step 4: Configure what.toml

[database]
type = "supabase"

[supabase]
project_url = "${SUPABASE_URL}"
api_key = "${SUPABASE_SERVICE_KEY}"

Step 5: Set Environment Variables

SUPABASE_URL=https://xyzcompany.supabase.co
SUPABASE_SERVICE_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Choosing a Backend

All backends use the same local: fetch syntax and form actions. Your templates don't change when you switch backends.