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 (queries, mutations, actions, and reactive subscriptions), see our 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:
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 /ingestwith file upload,POST /searchwith 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 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:
What you get from this:
- Automatic request validation: input types inferred from column schema
- Multipart file uploads: media columns accept
UploadFiledirectly - 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_routefor 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:
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.
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.
See It in Action: The Starter Kit#
The 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 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: clone and explore
- Starter Kit Announcement: walkthrough of both deployment patterns
- FastAPIRouter Reference: 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#
- The Triforce of AI Infrastructure: why storage, orchestration, and retrieval must be one system
- Declarative vs. Imperative AI Pipelines: the programming model underneath
- Data Is All You Need: why the data layer is the new bottleneck
- Iterate on Data, Not Infrastructure: the experimentation loop schema-driven infra enables
- Deconstructing the AI Frankenstein Stack: what schema-driven infrastructure replaces
- AI Transformations Belong in the Schema: why computed columns replace orchestrators and queues
- Pixeltable Documentation: full reference
