Frontend for Airtable
A front-end for Airtable that runs at database speed
Airtable is a good place to keep operational data and a poor place to put clients, field staff or anyone who should see only their own rows. An Airtable front-end fixes that: an app with logins, roles and clean screens, with the base still underneath.
Emberblocks does it differently from tools that call Airtable's API on every page load. It mirrors the base into Postgres and keeps both sides in sync, so the app is fast, Airtable's five-requests-per-second limit never bites, and you have a database you own if you ever want to leave.
Builders are always free. Facts about other products on this page were last checked on . Tell us if something is out of date: hello@emberblocks.com.
Why mirror instead of proxy
Speed
Airtable's API returns 100 records per call and allows five calls per second per base. One busy table view would use the whole budget. The Postgres mirror serves pages in milliseconds.
Two-way, within seconds
Edits made in the app are written to the mirror and pushed to Airtable through a transactional outbox. Changes made in Airtable arrive through Airtable's own change webhooks.
Real filters and formulas
Because the app reads Postgres, filters, sorts, groups, search and formulas work on every field at any size, and the API's limits do not apply.
Roles and per-user rows
Roles decide views and fields; per-user record filters show each client or rep only their rows. App users can come from a table in the base.
Workflows on Airtable data
Workflows run when a row is created, updated or deleted, on a schedule, or from a button; steps update records, send email, call webhooks, branch on conditions and run code.
An exit you own
The mirror is a normal Postgres schema. Switch the app's source to it or to your own Postgres and disconnect Airtable whenever you like.
How it works
- 1
Connect or import the data
Start on a built-in database, your own Postgres (Supabase, Neon, RDS, anything that speaks Postgres) or an Airtable base, or upload a CSV. Tables and columns are detected.
- 2
Describe the app, or start from a template
Ember drafts tables, views and workflows from a sentence or two. Or open one of ten working templates in the editor without an account.
- 3
Arrange the blocks
Drag tables, cards, record pages, kanban boards, calendars, maps, timelines, charts, stats, forms, buttons, comments, activity feeds, file viewers, signatures, barcodes and embeds onto a grid. Each block reads a table; filters, sorts, groups and formulas are configured in the inspector.
- 4
Set roles and publish
Roles decide which views a user sees and which fields they can read or edit; app users can be loaded from a table in your own data. Every publish is a versioned snapshot you can inspect and roll back, with a stable and a latest channel.
What you get in Emberblocks
Your data, live
Start on a built-in database, your own Postgres (Supabase, Neon, RDS, anything that speaks Postgres) or an Airtable base. Apps read and write live rows, so there are no exports to keep in sync.
Blocks on a grid
Drag tables, cards, record pages, kanban boards, calendars, maps, timelines, charts, stats, forms, buttons, comments, activity feeds, file viewers, signatures, barcodes and embeds onto a grid and wire them to tables. What you arrange is exactly what your team gets.
Real field types
Fields include text, email, phone, URL, number, boolean, date, date-time, time, duration, select, multi-select, reference, multi-reference, image, file, signature, address and JSON. Barcode scanning and signatures work in the browser without a native app.
Workflows
Workflows run when a row is created, updated or deleted, on a schedule, or from a button; steps update records, send email, call webhooks, branch on conditions and run code.
Roles and permissions
Roles decide which views a user sees and which fields they can read or edit; app users can be loaded from a table in your own data.
Publishing like software
Every publish is a versioned snapshot you can inspect and roll back, with a stable and a latest channel.
Phones and offline
Published apps are responsive, install on a phone's home screen, and queue edits made offline until the connection is back.
AI where it helps
Ember drafts a first version of an app from a plain-language description, and end users can ask questions of the data in plain language when you turn it on.
Questions
- Does it support linked records, attachments and formulas?
- Linked records become reference and multi-reference fields, attachments become file and image fields, and Airtable formula results sync as read-only values. Emberblocks formulas can compute on top of them.
- What happens if Airtable is down or rate-limited?
- The app keeps working on the mirror. Outgoing edits wait in the outbox and are delivered when Airtable accepts them again.
- Can I use it as an Airtable Interfaces replacement?
- Yes. See the Airtable Interfaces migration guide for a page-by-page mapping. Builders are never charged, and plans are priced by app users rather than seats.
- How is Emberblocks priced?
- Builders are always free. Paid plans are priced by the number of people who sign in to your published apps: Starter $29, Pro $79 and Business $199 a month billed yearly. Every new workspace starts with a 14-day Pro trial, no card needed, and there is a free plan after that. Full details on the pricing page.
- What does Emberblocks not do yet?
- Custom domains, SSO and an Enterprise plan are not available yet. There is no live Google Sheets connector (import the sheet as CSV instead). Apps run in the browser and install to the home screen; there are no App Store or Play Store builds.
Try it on your own data.
Every workspace starts with a 14-day Pro trial without a card. You can also open a template in the editor first and sign up only when you want to keep it.