Spiral extensions package domain-specific data access behind SQL table functions and typed outputs. They are the bridge between relational planning and modality-specific work such as image decode, video frame sampling, document chunking, tensor loading, or custom artifact generation.
An extension should make a domain feel relational first:
- Discover files, manifests, or external records as tables.
- Emit metadata and deferred references before reading expensive payload bytes.
- Let SQL filter, join, sample, and order those rows.
- Materialize only the values needed for preview, export, artifact creation, or model-ready batches.
The Extensions pages separate implemented primitives from directional modality-package contracts. Blob and JPEG/EXIF are documented as current behavior. Video, audio, document, tensor, and custom-extension pages are marked Experimental: Contact Us until their public package contracts are implemented.
Why table functions
Most modality-specific data starts outside a neat SQL table:
- object-store prefixes
- manifests
- document folders
- media files
- embedding stores
- application records with external payloads
An extension table function turns that source into a relation with documented columns. Users can then use the same SQL language for discovery, filtering, joining, sampling, and planning materialization.
Extension boundaries
An extension owns domain-specific concerns:
- how files or records are discovered
- which metadata columns are exposed
- which logical reference types are emitted
- how expensive values are materialized
- which caches, credentials, or decoders are required
The core SQL engine owns relation planning and execution. That split keeps extension APIs user-facing without moving engine internals into the docs.