Data sources
Apps read and write live data from three kinds of sources — the built-in Ember database, a two-way Airtable mirror, and your own Postgres — freely mixed within one app.
Ember tables
The built-in database needs zero setup: up to 50 tables, 60 columns each. Every table gets an automatic id and creation timestamp, plus a record label — the field (optionally with an image) that represents rows in references, cards, and search.
| Setting | Options | What it does |
|---|---|---|
| text / email / phone / url | — | Text values with format-aware rendering (mail, call, and link affordances). |
| number | — | Numeric values — sortable, chartable, aggregatable. |
| boolean | — | True/false, rendered as a checkbox or switch. |
| date / datetime | — | Calendar values, powering timelines, calendars, and date filters. |
| select | up to 50 options | One value from a fixed option list — kanban lanes, statuses, categories. |
| multi-select | up to 50 options | Any number of values from a fixed option list — tags, categories, skills. |
| reference | — | A link to a row of another table — the relational glue for lookups, rollups, and related-row filters. |
| image / file | — | Uploads (≤10 MB), stored and served automatically. |
| json | — | Structured payloads from integrations. |
Airtable
- Two-way mirror: Airtable changes arrive via webhooks; app edits push back.
- Schema lives in Airtable: add fields there, then
Refresh schemain Emberblocks. Removed fields are kept locally, never silently dropped. - Recovery tools:
Pull nowapplies pending changes;Full re-syncre-reads the whole base if the mirror drifts. - Attachments are re-hosted so images keep working in your app.
Postgres
Connect your own database and build directly on production tables. Writes are opt-in per table and require a primary key — until then the table is read-only everywhere.