SQLite Can Handle Your Website. Yes, Yours.

A blog is 99% reads, 1% writes. SQLite's strongest workload. No concurrent write pressure. Pages load from a single file — no network hop to a database server.

CREATE TABLE posts (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  slug TEXT UNIQUE NOT NULL,
  title TEXT NOT NULL,
  content TEXT NOT NULL,
  published INTEGER DEFAULT 0,
  created_at TEXT DEFAULT (datetime('now')),
  updated_at TEXT DEFAULT (datetime('now'))
);

CREATE TABLE tags (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT UNIQUE NOT NULL
);

CREATE TABLE post_tags (
  post_id INTEGER REFERENCES posts(id),
  tag_id INTEGER REFERENCES tags(id),
  PRIMARY KEY (post_id, tag_id)
);

CREATE INDEX idx_posts_slug ON posts(slug);
CREATE INDEX idx_posts_published ON posts(published, created_at DESC);

Why PostgreSQL is overkill: You'd need a running Postgres server, connection pooling (PgBouncer), a managed instance ($15+/month), and monitoring — all to serve articles that change once a day. SQLite does it from a single file, for free, with faster reads.

Comments are a classic "people think they need Postgres for this" workload. Even a popular blog gets maybe 50–200 comments per day. That's one write every 7 minutes. SQLite handles thousands of writes per second.

CREATE TABLE comments (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  post_id INTEGER NOT NULL REFERENCES posts(id),
  parent_id INTEGER REFERENCES comments(id),  -- threaded replies
  author_name TEXT NOT NULL,
  author_email TEXT,
  body TEXT NOT NULL,
  approved INTEGER DEFAULT 0,
  created_at TEXT DEFAULT (datetime('now'))
);

CREATE INDEX idx_comments_post ON comments(post_id, approved, created_at);
CREATE INDEX idx_comments_parent ON comments(parent_id);

Fetching all approved comments for a post:

SELECT id, parent_id, author_name, body, created_at
FROM comments
WHERE post_id = ? AND approved = 1
ORDER BY created_at ASC;

On a 100,000-comment table with proper indexes, this typically returns in under 1ms — see our SQLite performance guide for benchmarking tips.

This one surprises people. "An online store on SQLite? That can't be safe." But think about the actual workload: product catalog reads (fast), cart updates (a few writes per user session), order placement (one write per checkout). That's nothing.

CREATE TABLE products (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT NOT NULL,
  slug TEXT UNIQUE NOT NULL,
  description TEXT,
  price_cents INTEGER NOT NULL,
  stock INTEGER DEFAULT 0,
  category_id INTEGER REFERENCES categories(id),
  active INTEGER DEFAULT 1,
  created_at TEXT DEFAULT (datetime('now'))
);

CREATE TABLE orders (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  user_id INTEGER REFERENCES users(id),
  status TEXT DEFAULT 'pending',  -- pending, paid, shipped, delivered
  total_cents INTEGER NOT NULL,
  shipping_address TEXT,
  created_at TEXT DEFAULT (datetime('now'))
);

CREATE TABLE order_items (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  order_id INTEGER NOT NULL REFERENCES orders(id),
  product_id INTEGER NOT NULL REFERENCES products(id),
  quantity INTEGER NOT NULL,
  price_cents INTEGER NOT NULL  -- price at time of purchase
);

CREATE INDEX idx_products_category ON products(category_id, active);
CREATE INDEX idx_products_slug ON products(slug);
CREATE INDEX idx_orders_user ON orders(user_id, created_at DESC);
CREATE INDEX idx_order_items_order ON order_items(order_id);

A store with 10,000 products and 200 orders/day? SQLite handles that without breaking a sweat. Shopify powers millions of merchants worldwide — but your store isn't Shopify. It's one store. One database. One file.

User tables, sessions, password resets, email verification tokens — all classic CRUD operations with minimal write pressure.

CREATE TABLE users (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  email TEXT UNIQUE NOT NULL,
  name TEXT,
  password_hash TEXT NOT NULL,
  email_verified INTEGER DEFAULT 0,
  created_at TEXT DEFAULT (datetime('now'))
);

CREATE TABLE sessions (
  id TEXT PRIMARY KEY,  -- session token
  user_id INTEGER NOT NULL REFERENCES users(id),
  expires_at TEXT NOT NULL
);

CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_sessions_user ON sessions(user_id);
CREATE INDEX idx_sessions_expires ON sessions(expires_at);

Even with 100,000 registered users and 5,000 daily active sessions, the database stays under 50MB. SQLite loads that entirely into memory and serves every query in microseconds.

Internal dashboards, admin panels, project management tools, CRMs — these are typically used by a small team (1–50 people). The data volumes are modest, the query patterns are simple, and uptime matters more than raw throughput.

CREATE TABLE projects (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT NOT NULL,
  owner_id INTEGER REFERENCES users(id),
  status TEXT DEFAULT 'active',
  created_at TEXT DEFAULT (datetime('now'))
);

CREATE TABLE tasks (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  project_id INTEGER NOT NULL REFERENCES projects(id),
  title TEXT NOT NULL,
  description TEXT,
  assignee_id INTEGER REFERENCES users(id),
  status TEXT DEFAULT 'todo',  -- todo, in_progress, done
  priority INTEGER DEFAULT 0,
  due_date TEXT,
  created_at TEXT DEFAULT (datetime('now'))
);

CREATE INDEX idx_tasks_project ON tasks(project_id, status);
CREATE INDEX idx_tasks_assignee ON tasks(assignee_id, status);

SQLite's advantage here: zero operational overhead. No database server to monitor, patch, or restart. Back up the entire database by copying one file. Restore by copying it back.

Landing pages with a "Join the waitlist" form. Contact forms. Newsletter signups. These are append-only workloads — the simplest possible database pattern.

CREATE TABLE waitlist (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  email TEXT UNIQUE NOT NULL,
  name TEXT,
  source TEXT,  -- where they signed up from
  created_at TEXT DEFAULT (datetime('now'))
);

CREATE TABLE contact_messages (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT NOT NULL,
  email TEXT NOT NULL,
  message TEXT NOT NULL,
  read INTEGER DEFAULT 0,
  created_at TEXT DEFAULT (datetime('now'))
);

You do not need a $25/month Supabase instance for a waitlist. One SQLite file. Done.

Page views, button clicks, feature usage tracking. For small-to-medium sites, this is a write-heavy but low-volume workload — perfect for SQLite with WAL mode and batched inserts.

CREATE TABLE events (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  event_type TEXT NOT NULL,
  page TEXT,
  referrer TEXT,
  user_agent TEXT,
  ip_hash TEXT,  -- hashed for privacy
  created_at TEXT DEFAULT (datetime('now'))
);

CREATE INDEX idx_events_type_date ON events(event_type, created_at);
CREATE INDEX idx_events_page ON events(page, created_at);

Query your daily page views:

SELECT page, COUNT(*) as views
FROM events
WHERE event_type = 'pageview'
  AND created_at >= date('now', '-7 days')
GROUP BY page
ORDER BY views DESC
LIMIT 20;

With proper indexes, this aggregation runs in milliseconds — even on millions of rows.

API backends for mobile apps, SPAs, or third-party integrations. If your API serves under 10,000 requests per minute (which covers the vast majority of apps), SQLite handles it trivially.

// SvelteKit API route with D1 (SQLite at the edge)
export async function GET({ url, platform }) {
  const db = platform.env.DB;
  const page = Number(url.searchParams.get('page') || 1);
  const limit = 20;
  const offset = (page - 1) * limit;

  const products = await db
    .prepare('SELECT id, name, slug, price_cents FROM products WHERE active = 1 ORDER BY created_at DESC LIMIT ? OFFSET ?')
    .bind(limit, offset)
    .all();

  return Response.json(products.results);
}

Zero connection pooling. Zero ORM configuration. Bind the database, write the query, return the result. See the full tutorial.