Databases & content

Every site has a built-in database. There's nothing to provision or connect — you define tables, and your pages and handlers read and write them. It serves two distinct jobs: content the site author manages, and data the site collects at runtime.

Two kinds of data

• Author-managed content — articles, products, team bios, listings. Structured records that make up the site's content, editable in the app or via the CLI.
• Runtime data — form submissions, user records, bookings, anything visitors create. Written by your handlers as the site runs.

Both live in the same database and are queried the same way.

Defining tables

You describe a table with a schema — its fields and their types. Fields can be text, numbers, dates, booleans, references to other records, and file attachments. Schemas can evolve safely over time: adding, renaming, and removing fields is supported, and publishing protects you from changes that would silently discard data.

Querying and relationships

• Indexes and search — mark fields for fast lookups and full-text search across records.
• Unique constraints — enforce that a value (like an email) appears once.
• Relationships — link records across tables, with cascading delete so dependents are cleaned up.
• Aggregates — maintain running counts and sums without recomputing them each time.

Working with content

• Approval queues — submissions can be held for review before they go live, so user-generated content isn't published blind.
• New-record notifications — get an email when a record is created (a new lead, a new booking).
• Soft delete and recovery — deleted records are recoverable for a window of time.
• File attachments — attach uploaded files to records; sensitive files stay behind access control rather than being publicly addressable.

Managing data

You can browse and edit records in the app's content tools, or from the CLI with acira db for runtime tables and acira backup for point-in-time recovery. See Deployments & backups.