---
title: "Schema-Driven Infrastructure: What Vercel Did for Frontends, Pixeltable Does for AI"
date: "2026-05-12"
author: "Pierre Brunelle"
tags:
  - AI Infrastructure
  - Architecture
  - Schema-Driven
  - FastAPI
  - Developer Experience
  - Declarative
  - Multimodal AI
description: "Vercel proved that framework structure can drive deployment infrastructure: no Terraform, no YAML, no ops. Pixeltable applies the same principle to AI backends: your table schema IS your infrastructure specification. Define columns, and storage, processing, indexing, and serving materialize automatically."
url: "https://pixeltable.com/blog/schema-driven-infrastructure-ai"
---

# Schema-Driven Infrastructure: What Vercel Did for Frontends, Pixeltable Does for AI

**Summary:** Vercel popularized "framework-driven infrastructure": deploy a Next.js app and the platform infers routing, serverless functions, edge config, and CDN caching from your code structure. No Terraform. No YAML. No ops team. Pixeltable applies the same principle to AI backends: define a table schema with computed columns, and storage, media processing, embedding indexes, model orchestration, and HTTP serving all materialize from that schema. We call this **schema-driven infrastructure**.

 
## The Vercel Insight

 
Before Vercel, deploying a web application meant configuring Nginx, provisioning load balancers, setting up CDN rules, wiring serverless functions, and managing a CI/CD pipeline. Every team reinvented this stack. Vercel's breakthrough was simple: **your framework already encodes the deployment intent**.

 
A file at `app/api/users/route.ts` IS a serverless function. A file at `app/page.tsx` IS a server-rendered page. A `next.config.js` with image optimization enabled IS CDN configuration. The framework structure is the infrastructure specification. Vercel just reads it and provisions accordingly.

 
This eliminated an entire category of work. Frontend developers stopped thinking about infrastructure and started thinking about products.

 
If you already know [Convex](https://docs.convex.dev/home) (queries, mutations, actions, and reactive subscriptions), see our [Convex Developers' Guide to Pixeltable](/blog/convex-developers-guide-to-pixeltable) for a side-by-side mapping of those primitives onto schema-driven infrastructure.

 
## AI Backends Today: The Opposite of Framework-Driven

 
Now look at how teams build AI backends. A typical multimodal application requires:

 

 - **Blob storage** (S3/GCS) for raw media

 - **A metadata database** (Postgres) for structured data

 - **A vector database** (Pinecone/Weaviate) for embeddings

 - **Media processing** (FFmpeg, Pillow, custom scripts) for transformations

 - **An orchestrator** (Airflow/Dagster) to coordinate it all

 - **LLM glue** (LangChain/custom code) for model calls

 - **A serving layer** (FastAPI + hand-written routes) to expose it

 

 
Each service is configured independently. None knows about the others. The "architecture" lives in your head, in glue scripts, and in YAML files spread across repos. There's no single source of truth that says "here's what this system does."

 
This is the pre-Vercel world for AI. Teams spend weeks on infrastructure before writing their first real feature. Change an embedding model and you rebuild three pipelines. Add a modality and you add a service. Debug a bad retrieval result and you trace through five systems.

 
## The Schema IS the Infrastructure

 
Pixeltable inverts this. Your table schema (columns, types, computed expressions, embedding indexes) is a complete description of what your AI backend does. The system reads it and provisions accordingly:

 
| Schema Declaration | Infrastructure That Materializes |
| --- | --- |
| Column of type ImageType | Managed media storage with deduplication |
| Computed column calling openai.chat_completions() | Rate-limited, retry-aware LLM orchestration |
| add_embedding_index() on a text column | Vector index with incremental updates |
| View with document_splitter iterator | Automatic chunking pipeline on insert |
| @pxt.query function | Parameterized retrieval with similarity search |
| FastAPIRouter.add_insert_route() | HTTP endpoint with validation and media handling |

 
No Airflow DAGs. No vector DB configuration. No S3 bucket policies. No custom media processing scripts. The schema declares intent; the system handles implementation.

 
## Concrete Example: From Schema to Production API

 
Here's a complete AI application (document ingestion, chunking, embedding, similarity search, and HTTP serving) expressed as schema:

 
```python
import pixeltable as pxt
from pixeltable.functions.document import document_splitter
from pixeltable.functions.huggingface import sentence_transformer
from pixeltable.serving import FastAPIRouter

# 1. Define the table (→ storage materializes)
docs = pxt.create_table('app.documents', {
 'document': pxt.Document,
 'title': pxt.String,
})

# 2. Define a view with chunking (→ processing pipeline materializes)
chunks = pxt.create_view('app.chunks', docs, iterator=document_splitter(
 document=docs.document,
 separators='sentence',
 metadata='title,heading'
))

# 3. Define an embedding (→ vector index materializes)
embed = sentence_transformer.using(model_id='intfloat/e5-large-v2')
chunks.add_embedding_index('idx', string_col='text', embedding=embed)

# 4. Define a query (→ retrieval logic materializes)
@pxt.query
def search(query_text: str, limit: int = 5):
 sim = chunks.idx.similarity(string=query_text)
 return chunks.order_by(sim, asc=False).select(
 chunks.text, similarity=sim
 ).limit(limit)

# 5. Define HTTP serving (→ API endpoint materializes)
router = FastAPIRouter()
router.add_insert_route(docs, path='/ingest', inputs=['title'],
 uploadfile_inputs=['document'])
router.add_query_route(path='/search', query=search)
```

 
That's it. ~25 lines. No infrastructure code, no config files, no service mesh. You get:

 

 - Persistent document storage with versioning

 - Automatic sentence-level chunking on every insert

 - Incrementally-updated vector embeddings

 - Similarity search with a single function call

 - Two HTTP endpoints (`POST /ingest` with file upload, `POST /search` with JSON)

 

 
Every piece of infrastructure was inferred from the schema. Just like Vercel infers CDN rules from `next.config.js`.

 
## FastAPIRouter: The Serving Layer That Completes the Picture

 
The [`FastAPIRouter`](https://docs.pixeltable.com/sdk/latest/fastapirouter) is what makes schema-driven infrastructure end-to-end. It takes table operations (inserts, updates, deletes, queries) and exposes them as production-ready HTTP endpoints with zero boilerplate:

 
```python
from pixeltable.serving import FastAPIRouter

router = FastAPIRouter()

# Table insert → HTTP POST with file upload support
router.add_insert_route(
 media_table, path='/upload',
 inputs=['title'],
 uploadfile_inputs=['image'],
 outputs=['title', 'thumbnail', 'embedding_text']
)

# @pxt.query → HTTP POST with JSON body
router.add_query_route(path='/search', query=similarity_search)

# Table insert → HTTP POST that returns generated media directly
router.add_insert_route(
 generation_table, path='/generate',
 inputs=['prompt'],
 outputs=['result_image'],
 return_fileresponse=True
)

# Background processing for heavy workloads
router.add_insert_route(
 video_table, path='/process-video',
 uploadfile_inputs=['video'],
 background=True # returns job_url for polling
)
```

 
What you get from this:

 

 - **Automatic request validation:** input types inferred from column schema

 - **Multipart file uploads:** media columns accept `UploadFile` directly

 - **FileResponse:** return generated images/audio/video as binary responses

 - **Background jobs:** long-running inserts return a polling URL

 - **SQL export:** every insert/update can replicate to an external database

 - **Decorator pattern:** `@router.insert_route` for custom post-processing

 

 
The schema drives the entire API surface. Column types determine request/response shapes. Computed columns determine what processing happens. The router just connects HTTP to the schema.

 
## Schema-Driven Data Flow: export_sql

 
The analogy extends to data flow between systems. With `export_sql`, every insert to your Pixeltable schema can simultaneously write to an external serving database:

 
```python
from pixeltable.serving import FastAPIRouter, SqlExport

router = FastAPIRouter()
router.add_insert_route(
 docs, path='/ingest',
 inputs=['title'],
 uploadfile_inputs=['document'],
 outputs=['title', 'summary', 'category'],
 export_sql=SqlExport(
 db_connect='postgresql+psycopg://user:pw@host/prod',
 table='document_catalog',
 db_schema='public'
 )
)
```

 
One POST request triggers: file storage, chunking, embedding, LLM summarization (all via computed columns), AND replication of structured results to your production Postgres. Declared in the schema. No ETL pipeline. No cron job.

 
## The Analogy

 
| | Vercel (Framework-Driven) | Pixeltable (Schema-Driven) |
| --- | --- | --- |
| Source of truth | File structure + framework config | Table schema + computed columns |
| Storage | Static assets → CDN (inferred) | Media columns → managed blob storage (inferred) |
| Compute | route.ts → serverless function | Computed column → orchestrated processing |
| Caching | ISR/SSG → edge cache (inferred) | Incremental computation → only new data processed |
| Search/Retrieval | N/A | add_embedding_index() → vector search |
| API layer | File-based routing (automatic) | FastAPIRouter (schema-derived endpoints) |
| What you write | React components + API handlers | Table definitions + UDFs + queries |
| What you skip | Nginx, load balancers, CDN rules, CI/CD | S3, Postgres, Pinecone, Airflow, FFmpeg, glue |

 
## Incremental by Default (The CDN Parallel)

 
Vercel's edge caching is automatic: pages are cached at the CDN and incrementally revalidated. You don't configure cache headers; the framework signals when content is stale.

 
Pixeltable's incremental computation works the same way. When you insert new data, only the new rows flow through computed columns. Existing results are untouched. When you change a computed column definition (swap an embedding model, adjust a prompt), only affected rows recompute. There's no "rebuild everything" step.

 
This is the equivalent of ISR for AI pipelines: [incremental by default, full recompute never required](/blog/iterate-on-data-not-infrastructure).

 
## Schema Portability: Dev to Production

 
Vercel's promise is "works on localhost, works in production." Same code, same behavior, different scale.

 
Pixeltable schemas are portable the same way. The schema you define on your laptop (with local storage and a SQLite catalog) is the same schema that runs in production with Postgres, cloud blob storage, and GPU-backed inference. No code changes. No "production mode" configs. The schema IS the application; the runtime figures out the rest.

 
```python
# Same schema works everywhere:
# - Local dev: SQLite catalog, local filesystem
# - Docker: Postgres catalog, mounted volume
# - Production: Postgres catalog, S3 media, GPU inference

import pixeltable as pxt
docs = pxt.create_table('app.documents', {...})
docs.add_computed_column(summary=llm_summarize(docs.text))
docs.add_embedding_index('idx', string_col='text', embedding=embed)
```

 
## See It in Action: The Starter Kit

 
The [Pixeltable Starter Kit](https://github.com/pixeltable/pixeltable-starter-kit) is a reference implementation of schema-driven infrastructure. One `setup_pixeltable.py` file defines the entire backend: tables, views, computed columns, embedding indexes, and an 11-column agent pipeline. The [`FastAPIRouter`](https://docs.pixeltable.com/sdk/latest/fastapirouter) turns those declarations into a production API.

 
There's no Terraform. No Docker Compose for dependencies. No vector database to provision. The schema is the infrastructure, and it fits in one readable Python file.

 

 - **[Starter Kit on GitHub](https://github.com/pixeltable/pixeltable-starter-kit)**: clone and explore

 - **[Starter Kit Announcement](/blog/pixeltable-starter-kit-launch)**: walkthrough of both deployment patterns

 - **[FastAPIRouter Reference](https://docs.pixeltable.com/sdk/latest/fastapirouter)**: full API documentation

 

 
## What This Means for AI Teams

 
Framework-driven infrastructure changed frontend development because it eliminated a class of work that wasn't differentiating. Nobody's competitive advantage was their Nginx config.

 
Schema-driven infrastructure makes the same argument for AI backends. Your competitive advantage isn't your S3 bucket policy, your Airflow DAG, or your vector database tuning. It's your data, your models, and your domain logic. Everything else is undifferentiated infrastructure that should be inferred from a declaration of intent.

 
Define the schema. Ship the product.

 
## Further Reading

 

 - [Never Fuck With Your Backend Anymore](/blog/never-fuck-with-your-backend-anymore): the updated loop — class-based `TableModel` in `app.py`, then `pxt schema update`

 - [The Triforce of AI Infrastructure](/blog/triforce-storage-orchestration-retrieval): why storage, orchestration, and retrieval must be one system

 - [Declarative vs. Imperative AI Pipelines](/blog/declarative-vs-imperative-ai-pipelines): the programming model underneath

 - [Data Is All You Need](/blog/data-is-all-you-need): why the data layer is the new bottleneck

 - [Iterate on Data, Not Infrastructure](/blog/iterate-on-data-not-infrastructure): the experimentation loop schema-driven infra enables

 - [Deconstructing the AI Frankenstein Stack](/blog/deconstructing-ai-frankenstein-stack): what schema-driven infrastructure replaces

 - [AI Transformations Belong in the Schema](/blog/ai-transformations-in-the-schema): why computed columns replace orchestrators and queues

 - [Pixeltable Documentation](https://docs.pixeltable.com): full reference