Every time a marketing team member edits a blog post title, a developer gets paged to redeploy the site. That trade-off has defined content management for a generation: either page-build performance and a brittle deployment process, or instant publishing via a headless CMS with a monthly SaaS bill. AIKit's D1 Content Pipeline eliminates the trade-off entirely. By storing content in Cloudflare D1 and querying it live at request time via Astro SSR, AIKit achieves instant publishing with zero build steps, zero redeployments, and zero SaaS overhead.
The Problem
Traditional content pipelines for static site generators follow a well-worn path. A content author writes a post in a CMS or a markdown file. The change is committed to a Git repository. A CI/CD pipeline runs a full build -- fetching all content, rendering every page, generating static HTML for the entire site. The build output is then deployed to a CDN or origin server. This process typically takes anywhere from 30 seconds to several minutes.
The friction is tolerable when developers are the only editors. But in practice, blog content is written by marketing teams, product managers, and technical writers -- people who should never need to touch a Git workflow. The result is a bottleneck where every typo fix, title tweak, or image swap requires a developer's involvement.
Worse, the build-and-deploy cycle imposes a latency floor. Even a 60-second deployment means content cannot be published in real time. Time-sensitive announcements, patch notes, or corrections are delayed. And every build consumes CI minutes, generates cache-invalidation thundering herds, and increases the risk of a broken deploy.
The Solution
AIKit replaces the static-build pipeline with a live query paradigm. Instead of rendering all content at build time, Astro runs in Server-Side Rendering (SSR) mode on Cloudflare Workers. When a request arrives for a blog post, the Worker queries D1 directly at the request edge and renders the page on the fly.
This means there is no build step for content changes. When an author hits "Publish," the content lands in D1 immediately. The next HTTP request to that post URL fetches the fresh data from D1, renders the Astro component, and returns HTML -- typically in under 50 milliseconds on the database query alone. The publisher, the builder, and the reader all see the same data at the same time.
Architecture
The publishing pipeline has three stages: ingestion, storage, and serving.
**Ingestion.** A content author submits a post via the Astro Studio admin panel, or via the Sanity Studio if the team is using Sanity as a writing interface. On submission, a webhook fires to a Cloudflare Worker that runs a Python script -- blog-publisher.py -- via Wrangler's D1 execute command.
**Storage.** The Python publisher script transforms the post payload (including Portable Text blocks, metadata, SEO fields, and revision history) into SQL INSERT statements. It executes them against D1 via `wrangler d1 execute`, which pushes the data into the `ec_posts` and `revisions` tables. The entire write operation completes in under one second.
**Serving.** Astro SSR, running on a Cloudflare Worker, intercepts incoming GET requests for blog post routes. The route handler performs a parameterized SELECT query against D1 to fetch the post by slug or ID. The result set includes the full body content in Portable Text JSON, frontmatter metadata, SEO fields, and computed reading time. Astro renders the page component with this data streamed directly from D1 and returns the HTML response.
The critical property of this architecture is that there is no cache layer between the author's publish action and the reader's request. While Cloudflare's edge cache may warm a popular post, the first request after a publish always hits D1 and returns the updated content. This means the publish latency is exactly the D1 write latency -- typically 50 to 200 milliseconds.
Implementation
The D1 database schema is designed around three core tables: `ec_posts`, `revisions`, and `ec_seo`. The schema handles a circular foreign key pattern between posts and their SEO metadata, which D1's deferred foreign key enforcement manages gracefully.
```sql
CREATE TABLE ec_posts (
id INTEGER PRIMARY KEY AUTOINCREMENT,
title TEXT NOT NULL,
slug TEXT UNIQUE NOT NULL,
body TEXT NOT NULL, -- Portable Text JSON array
excerpt TEXT,
category TEXT,
tags TEXT, -- JSON array stored as TEXT
author TEXT,
status TEXT DEFAULT 'draft', -- draft | published | archived
published_at DATETIME,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP,
reading_time_minutes INTEGER DEFAULT 0,
feature_image_url TEXT,
seo_id INTEGER,
FOREIGN KEY (seo_id) REFERENCES ec_seo(id)
);
CREATE TABLE revisions (
id INTEGER PRIMARY KEY AUTOINCREMENT,
post_id INTEGER NOT NULL,
title TEXT NOT NULL,
body TEXT NOT NULL,
excerpt TEXT,
version INTEGER NOT NULL,
editor TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
diff_summary TEXT,
FOREIGN KEY (post_id) REFERENCES ec_posts(id) ON DELETE CASCADE
);
CREATE TABLE ec_seo (
id INTEGER PRIMARY KEY AUTOINCREMENT,
post_id INTEGER UNIQUE NOT NULL,
meta_title TEXT,
meta_description TEXT,
canonical_url TEXT,
og_image TEXT,
og_title TEXT,
og_description TEXT,
twitter_card TEXT DEFAULT 'summary_large_image',
json_ld TEXT, -- JSON-LD structured data
noindex INTEGER DEFAULT 0,
FOREIGN KEY (post_id) REFERENCES ec_posts(id)
);
-- Indexes for common query patterns
CREATE INDEX idx_posts_slug ON ec_posts(slug);
CREATE INDEX idx_posts_status ON ec_posts(status);
CREATE INDEX idx_posts_published_at ON ec_posts(published_at);
CREATE INDEX idx_revisions_post_id ON revisions(post_id);
```
The circular foreign key -- `ec_posts.seo_id` references `ec_seo`, and `ec_seo.post_id` references `ec_posts` -- is resolved at insert time by inserting the post first with `seo_id` as NULL, inserting the SEO row with the post's generated ID, and then updating the post row with the SEO row's ID. D1 supports deferred foreign key enforcement via `PRAGMA defer_foreign_keys = ON`, which allows this pattern without error.
Body content is stored as Portable Text, Sanity's block-based JSON format. This preserves rich text structure -- headings, inline code, links, images, and blockquotes -- without relying on markdown parsing at render time. The Astro renderer walks the Portable Text blocks and maps each type to the corresponding Astro/HTML component.
Results
The D1 Content Pipeline has been in production for the full lifetime of the current ai-kit.net site. The database currently holds 18,268 kilobytes of content across 447 published posts, with zero content-related deployments.
Publish latency is effectively zero seconds from the user's perspective. When an author clicks "Publish," the webhook fires, the D1 execute completes in under 200 milliseconds, and the post is immediately queryable. The first reader request returns the new content without any deployment, cache flush, or build step.
Revision history is maintained for every edit, allowing rollback to any previous version. Each revision stores the full body content, title, and excerpt at the time of the edit, with a version number and editor identifier. This gives the content team the safety net of version control without requiring Git.
SEO metadata is managed through the `ec_seo` table, with dedicated fields for Open Graph, Twitter Card, and JSON-LD structured data. The meta title and description are stored separately from the post body, allowing search-engine-specific optimization without altering the visible content.
Key Takeaways
**Eliminate the build step for content.** Every minute saved on deployment is a minute of developer time reclaimed. With D1, content changes are instantaneous -- the database INSERT is the final step, not the first step in a pipeline.
**SSR does not mean slow.** Astro SSR on Cloudflare Workers with D1 back-end queries completes in well under 100 milliseconds for a typical page render. The database query itself accounts for 10 to 50 milliseconds, including network time from the Worker to D1's edge storage. With Cloudflare's global network, the round-trip rarely exceeds 30 milliseconds.
**Version control for content without Git.** The `revisions` table gives content authors full rollback capability without requiring developer intervention. Each edit is tracked, versioned, and replayable.
**Schema design matters at the edge.** The circular FK pattern between posts and SEO tables works seamlessly with D1's deferred constraint enforcement. Portable Text as a storage format provides rich-text fidelity without the ambiguity of raw markdown.
**The metrics speak clearly.** 447 posts, 18.3 MB of content, zero content deployments, and sub-200-millisecond publish latency. The D1 Content Pipeline proves that a small schema, a Python publisher script, and Astro SSR can replace an entire build-and-deploy content pipeline. For teams tired of redeploying every time a comma moves, this architecture offers a proven, open alternative.