Zapier Becoming System of Record
Diving deeper into
Zapier: The $7B Netflix of Productivity
disintermediating Airtable by building its own Zapier-native data store.
Analyzed 6 sources
Reviewing context
This move would turn Zapier from a pipe into a system of record. Today, many no code workflows use Zapier for logic and Airtable for storage, which means the workflow breaks across tools and Airtable owns the underlying rows. A Zapier native data store would let Zapier hold the records, run automations on them directly, and make more of its 3,000 plus app connections feel native instead of stitched together.
-
Airtable is strong because it is where teams actually keep operational data, in tables, records, views, apps, and automations. Once a marketing or ops team builds around that database, new use cases tend to appear and retention rises. Taking over that data layer is how Zapier would stop being only the logic layer.
-
The practical user benefit is simpler workflow design. Instead of pulling data out of HubSpot, writing it into Airtable, then triggering another Zap, Zapier could ingest data from SaaS apps once, store it in Tables, and let later steps read and update the same records inside one product.
-
This is part of a broader product convergence. Zapier has since added Tables and Interfaces, while Airtable built automations and integrations, and Retool paired workflows with database and UI products. The category is converging on one stack that combines storage, logic, and interface in one place.
The direction is toward bundled workflow platforms, not standalone automation tools. If Zapier keeps deepening its data layer, it can capture more of the workflow, raise switching costs, and compete for the full no code app stack instead of only the automation step in the middle.