Skip to main content

Code Organization

Separate schema definition from router logic. Schema Definition (schema.py):
  • Tables, views, computed columns, indexes, and agent-internal @pxt.query functions
  • Flat module with if_exists='ignore' for idempotency (no setup() wrapper, no _initialized flag)
  • Run once before starting workers: python schema.py
Router Files (routers/data.py, routers/search.py, etc.):
  • Call pxt.get_table() directly to get table handles
  • Define router-facing @pxt.query functions next to the routes that use them
  • No import schema needed; tables already exist from the init step
Configuration (config.py):
  • Externalizes model IDs, API keys, thresholds, connection strings
  • Uses environment variables (.env + python-dotenv) or secrets management
  • Never hardcodes secrets

Project Structure

Key Principles:
  • Schema separate from routers: schema.py defines tables/views/indexes. Router files define @pxt.query functions next to the routes that use them. No cross-imports needed.
  • Module UDFs (functions.py): Update when code changes; improve testability. Learn more
  • Idempotency: Use if_exists='ignore' to make schema.py safely re-runnable.
  • Built-in HTTP serving: For standard endpoints, consider pxt serve with a TOML config.
  • return_rows=True: Pass to insert()/update() to get computed column values back without a follow-up query. See HTTP Serving.
  • Multi-worker deployments: With --workers N, run python schema.py before uvicorn so schema creation happens once, not per worker (see Starter Kit Dockerfile).

Pixeltable Starter Kit

See this structure in action: a production-ready FastAPI + React app with schema definition, config, UDFs, and endpoint routers already wired up. Includes deployment configs for Docker, Helm, Terraform (EKS/GKE/AKS), and AWS CDK.

Storage Architecture

Pixeltable is an OLTP database built on embedded PostgreSQL. It uses multiple storage mechanisms:
Important Concept: Pixeltable directories (pxt.create_dir) are logical namespaces in the catalog, NOT filesystem directories.
How Media is Stored:
  • PostgreSQL stores only file paths/URLs, never raw media data.
  • Inserted local files: path stored, original file remains in place.
  • Inserted URLs: URL stored, file downloaded to File Cache on first access.
  • Generated media (computed columns): saved to Media Store (default: local, configurable to S3/GCS/Azure per-column).
  • File Cache size: configure via file_cache_size_g in ~/.pixeltable/config.toml. See configuration guide
For large datasets with remote media, consider increasing file cache size to avoid repeated downloads (default is 20% of available disk):

References, Not Copies

Unlike vector databases that require ingesting data into their own storage format, Pixeltable stores references to external files. Your original media stays in S3/GCS/Azure; only computed results (embeddings, metadata, generated media) are stored locally or in configured cloud buckets. This means:
  • No data duplication — you don’t pay for storage twice.
  • Schema changes don’t require re-upload — add a column, not a migration script.
  • Works with existing storage — point Pixeltable at your current buckets.
Deployment-Specific Storage Patterns: Batch Processing:
  • Pixeltable storage can be ephemeral (re-computable).
  • Processing results exported to external RDBMS via export_sql and media to blob storage via destination.
  • Reference input media from S3/GCS/Azure URIs.
Full Backend:
  • Pixeltable IS the RDBMS (embedded PostgreSQL, not replaceable).
  • Requires persistent volume at ~/.pixeltable (pgdata, media, file_cache).
  • Media Store configurable to S3/GCS/Azure buckets for generated files.
Declarative Serving (pxt serve):
  • Same persistent storage as Full Backend.
  • API routes declared in pyproject.toml, no hand-written endpoint code.
All Starter Kit deployment configs set PIXELTABLE_HOME=/data/pixeltable pointing to persistent storage (Docker volumes, K8s PVCs, or EFS). For large media workloads, configure external blob storage:

Dependency Management

Virtual Environments: Use venv, conda, or uv to isolate dependencies. Dependencies (pyproject.toml):
  • Use pyproject.toml with uv or pip for dependency management
  • Include integration packages (e.g., openai, sentence-transformers)
  • Test updates in staging before production

Data Interoperability

Pixeltable integrates with existing data pipelines via import/export capabilities. See the Import/Export SDK reference for full details. Import: Export:
Last modified on July 14, 2026