Database
A headless content store for people, agents and scripts.
What Database is for
Database is a headless content store: people, agents and scripts read and write structured tables and rows directly through the public API, as with a headless CMS. It holds content such as itineraries and catalogs, independently of the applications that use it. It is neither an application's private runtime database nor a data warehouse.
| Role | Who uses it | Lifecycle | Where to store it |
|---|---|---|---|
| Content store | People, agents and scripts; applications can read it through public APIs | Content is edited and reused independently of application releases | Database for structured content; File for files; Knowledge for searchable knowledge |
| Application runtime store | Application code managing orders, sessions and business rules | State changes as the application runs, under its own business constraints | The application's own d1, kv or r2 components |
| Data warehouse | Analysts and reporting pipelines | Historical data accumulated for analysis | A dedicated analytics warehouse, outside Database |
A typical pattern is content store → build → publish to Application: read itinerary content from Database, build site files, then use praxis.application.publish to upload, version and deploy them. Editing the source content does not update those published files; build and publish again to include the edits.
Each database is an isolated unit with its own tables, fields, rows and events.
Create databases and table structure through the Database API; read and write rows with the official supabase-js client. Both row access URLs for a database share the same data.
- Quickstart: create a database and table, then write and read your first row.
- Concepts: field types, links, versions and recovery.
- Limits and errors: capacity and query boundaries.