How Paste9 is built on db9

Postgres — storage

Every paste is a row in a pastes table. Content, creation time, and expiration are all standard columns. No ORM, no abstraction — just SQL via the pg driver.

CREATE TABLE pastes (
  id TEXT PRIMARY KEY,
  content TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now(),
  expires_at TIMESTAMPTZ NOT NULL
);

Auto Embedding — semantic search

db9's built-in embedding extension generates vectors directly in SQL — no external embedding API needed. When a paste is created, its content is chunked and each chunk gets a vector.

-- Store chunks with auto-generated embeddings
INSERT INTO chunks (paste_id, idx, body, vec)
VALUES ($1, $2, $3, embedding($3));

-- Search by semantic similarity
SELECT body FROM chunks
WHERE paste_id = $1
ORDER BY vec <=> embedding($2)
LIMIT 1;

Agents don't need to read entire documents. A query like ?q=deployreturns only the relevant sections — powered entirely by db9's vector search.

pgvector — similarity ranking

Chunks are stored with a VECTOR column. The cosine distance operator <=> ranks results by relevance. Combined with LIMIT, agents get precisely the sections they need.

Expiration — auto-cleanup

Each paste has an expires_at timestamp (default: 300 minutes). Reads refresh the expiration — active pastes stay alive, idle ones expire naturally. Expired rows are invisible to queries and cleaned up lazily. Chunks are deleted automatically via ON DELETE CASCADE.

-- Read refreshes expiration
UPDATE pastes
SET expires_at = now() + interval '300 minutes'
WHERE id = $1 AND expires_at > now()
RETURNING content;

pg_cron — scheduled cleanup

db9 supports pg_cron for recurring SQL tasks. Paste9 schedules an hourly job to physically delete expired rows — no external cron server, no Lambda, no worker process. The cleanup runs inside the database itself.

-- Runs every hour inside the database
SELECT cron.schedule('paste9_cleanup', '0 * * * *',
  $$DELETE FROM pastes WHERE expires_at < now()$$
);

As a fallback, each read request has a 1% chance of triggering cleanup — so even if pg_cron is unavailable, expired data is still eventually removed.

One database, zero infrastructure

The entire Paste9 service runs on:

• — One db9 serverless Postgres database
• — Next.js on Vercel (frontend + API routes)
• — No Redis, no S3, no queue, no cron server

db9 handles storage, vector embeddings, and expiration. Vercel handles HTTP. That's it.