When a self-hosted Baserow replaces Zapier Tables
If your lookup lists, queues or small datasets live in Zapier Tables, the main self-hosted replacement is Baserow, and n8n remains the workflow layer that reads and writes it. Zapier Tables sits inside a cloud-only service, so the data, the automations that touch it and the people who can change it all depend on Zapier's hosting. This page covers the table module only, not the rest of the Zapier suite, and it assumes your Zaps will keep running somewhere while the data moves.
Cost is probably not the reason to move. Zapier's pricing page lists Zapier Tables on all plans, with unlimited tables and 100 fields per table, and states that Tables triggers and actions do not count toward task usage. The reasons to move are therefore hosting, record ceilings, ownership and data location. Zapier's per-account record limits are 2,500 on Free, 100,000 on Pro and 500,000 on Team, with Enterprise limits by quote. Ask yourself whether your record count is near one of those ceilings, whether the table holds data that must stay in your own jurisdiction, and whether your team needs to version and back up that data on its own schedule.
Baserow is open core. Its non-premium and non-enterprise features are under the MIT License, which allows commercial and private use, while premium and enterprise features fall outside that grant. Before you plan around a feature such as single sign-on or role-based permissions, confirm which license tier it sits in, because the Baserow self-hosted license types documentation ties paid access to a specific license type per instance. Check that tier with Baserow before you commit to a design.
How Zapier Tables capabilities map to Baserow and n8n
This table maps each Zapier Tables capability to the Baserow feature or n8n node that covers it, and marks where the match is partial or unverified. Read the gap rows first, because they decide whether a straight move is possible or whether some tables need redesign. The main takeaway is that Baserow holds the data and n8n moves it, so both need checking against your own schema before cutover.
| Capability | Zapier Tables | Baserow and n8n | What to confirm |
|---|---|---|---|
| Tables and fields | Unlimited tables, 100 fields per table on all plans | Baserow tables within a database, with field types set per column | Confirm each field type you use exists in Baserow, since the Airtable importer skips formula, lookup and rollup fields |
| Record limits | 2,500 records on Free, 100,000 on Pro, 500,000 on Team per account | No record cap is set by the self-hosted MIT edition; Baserow cloud Free lists 3,000 rows per workspace | Size your instance and database storage against your own row counts, not the plan caps |
| Triggers and actions | Tables triggers and actions do not count toward task usage | n8n Baserow node for reads and writes, plus webhooks from Baserow to start workflows | Test trigger timing and webhook delivery in your own environment before retiring Zaps |
| Views and filters | Table views and filtered lists used by Zaps | Grid views with filters and sorts; the Airtable importer carries these over | Check that every filtered view your Zaps depend on is rebuilt in Baserow |
| User access | Access managed through Zapier account roles | Role-based permissions and audit logs are listed for Baserow Advanced; SSO requires an activated license | Confirm which roles and audit logs your access model needs and which license tier provides them |
| API access | Tables read and write through Zaps | Headless, API-first Baserow with tokens used by n8n credentials | Store the token in n8n credentials and confirm its scope covers each table |
| Import and export | Zap export is JSON only; Tables data export depends on the plan | CSV, Excel, XML and JSON import; Airtable import from a public share link | Confirm the export path for your current Zapier table data, since Zap JSON files do not carry table records |
| Automations | Zaps read and write tables | n8n workflows replace Zaps; Baserow automations and dashboards cover in-app steps | Rebuild each Zap as an n8n workflow and confirm n8n's Sustainable Use License fits your use |
Which open-source option fits which Zapier Tables use
Zapier Tables mix three jobs: lookup lists, work queues and small datasets that workflows read and write. Each job has a different best fit among self-hosted Baserow, its paid license tiers and lighter options inside n8n or PostgreSQL. The cards below set out when each fits, what it costs in trade-offs and what to confirm before you move data.
Baserow Community features for lookup lists
The Community features are MIT-licensed, which allows commercial and private use of the code that is not marked premium or enterprise. This fits shared lookup lists such as cost centers, region codes or approved vendors that several workflows read through the API. Check which features your use needs, since premium and enterprise features fall outside the MIT grant and some access controls depend on the paid tiers. Confirm the features you rely on with the Baserow documentation before you rely on them.
Baserow queues for workflow handoffs
A table with a status field can hold items waiting for a workflow step, with n8n polling or receiving a webhook to pick up the next row. This fits low-volume handoffs such as approval requests or retry lists where a row count stays modest. Write workers must update status fields in order, so define who claims a row and what happens when a run fails midway. Test concurrent updates before you put a busy queue on this path.
Baserow paid license tiers
Premium assigns seats to named users, while Advanced grants paid access to every user on the instance. Enterprise is priced through sales. An instance can run only one license type, so choose before rollout and avoid mixing seat models across teams. Single sign-on through SAML, OAuth 2.0 providers or OpenID Connect is available on Advanced and Enterprise with an activated license. Ask the vendor for a written quote that matches your user counts.
Single sign-on on Advanced and Enterprise
If your Zapier Tables access runs through corporate identity, single sign-on is the feature that matters most among the paid tiers. Premium does not include it, so a team that needs SSO on Premium must either accept local accounts or move to Advanced. Confirm the identity provider you use is supported and test group mapping before cutover. Review how departing staff lose access to the instance.
n8n data store or PostgreSQL for simple queues
For a small queue of short-lived items, n8n's own data store or a plain PostgreSQL table avoids running a spreadsheet interface at all. This suits machine-only state such as deduplication keys or cursor positions that no person edits. The trade-off is that business users lose the grid view, filters and attachments they had in Zapier Tables. Check whether your n8n plan or edition provides the storage you expect, and back up the database that holds it.
How Zapier Tables record limits compare with Baserow plans
Start by writing down your current record count for each Zapier Table and how fast it grows each month. Zapier's pricing page sets record limits per account rather than per table: 2,500 records on Free, 100,000 on Pro and 500,000 on Team, with Enterprise limits given by quote. Because the ceiling applies to the whole account, one busy queue can use up headroom meant for lookup lists. If your total sits near a tier boundary, or your growth would cross one within the next budget cycle, the Team plan figure is the one to plan around, and Enterprise is the only path above it.
Baserow does not use the same model. Its cloud Free tier lists 3,000 rows per workspace, and paid cloud tiers are priced per user, so the cloud figures answer a different question from Zapier's account ceiling. A self-hosted Baserow instance has no row cap set by the vendor. Your practical ceiling depends on your PostgreSQL sizing, storage, memory, backup window and the number of concurrent API calls your workflows make. Confirm the self-hosted limits for the exact version you install in its documentation and release notes, and do not assume a cloud figure applies to your server. Ask your team to run a load test with a copy of your largest table before you choose instance size.
Once you have the numbers, decide how much headroom you want and who will watch it. Record growth, table size and database storage in your monitoring stack, and set an alert well below the level where queries slow down in your own tests. Also confirm that your chosen Baserow license type does not change any row handling you rely on, since the Baserow self-hosted license types page describes which features each paid tier unlocks. Document the baseline and the growth assumption in the migration plan so the capacity decision can be reviewed at each renewal.
How n8n reads and writes Baserow during and after the move
During the transition, Zapier Tables and Baserow both hold the lookup lists, queues and small datasets while existing Zaps keep running. The usual pattern is for n8n workflows to write each new record to both stores, so that either system can answer a lookup while you verify that the two stay aligned. Plan this period around the data you copy into Baserow, because the Airtable importer and the CSV, Excel, XML and JSON imports described on Baserow's pricing page are one-time copies, not sync mechanisms.
- Dual writes: Each n8n workflow writes to Zapier Tables and to the matching Baserow table, and logs failures from either side.
- Reconciliation: Compare row counts and key fields between the two stores on a schedule you set, and record the results.
- Field mapping: Map Zapier Tables field types to Baserow field types in a written table before building any node, since some types do not carry over directly.
- Credential scope: Create a dedicated Baserow API token for n8n with the minimum table access it needs.
- Record limits: Confirm that Zapier Tables record limits on your plan still hold while both stores are populated.
Before cutover, confirm that every workflow writes to both sides without silent errors and that reconciliation has run cleanly for the period you agreed with the business owners.
After cutover, n8n reads and writes only Baserow through its API, and Zapier Tables is retired from every workflow. The change is mostly in the n8n nodes, which point at Baserow table and row endpoints instead of Zapier Tables. Keep the old Zapier Tables data exported and archived until the owners confirm that no consumer still depends on it.
- Node changes: Replace each Zapier Tables step with a Baserow node or HTTP Request node that calls the Baserow REST API.
- Lookups: Rebuild lookup logic so it queries Baserow filters rather than relying on Zapier's in-flow table lookups.
- Queues: If a Zapier Table acted as a queue, define how rows move from pending to done and who owns that status field.
- Access control: Use Baserow roles and the API token scope to limit what each workflow can change.
- Rollback path: Keep the dual-write workflows disabled but available until the first full business cycle has passed.
Before you turn off Zapier Tables access, check that every n8n workflow runs end to end against Baserow in a test environment and that the archived export opens and contains the expected records.
Teams that run n8n in queue mode split the work across a main instance, Redis and a pool of workers that all read and write workflow data in PostgreSQL. Credentials stored in that database are encrypted, so every worker and webhook processor must receive the same encryption key as the main instance or it cannot decrypt the Baserow API token. This matters most when workers are added or rebuilt during the move, because a mismatched key fails silently for some executions and not others.
- Shared encryption key: Provide the main instance's encryption key to every worker and webhook processor through your secret management process.
- PostgreSQL connection: Point all n8n processes at the same external PostgreSQL database, and confirm that connection settings match across hosts.
- Redis dependency: Confirm that the Redis instance used for execution passing is reachable from every worker.
- Key storage: Store the encryption key outside the n8n container image and restrict who can read it.
- Multi-main limits: Multi-main high availability is available only on Enterprise self-hosted deployments, so Community or Business setups run a single main instance.
Licensing also applies here. The Sustainable Use License permits use for your own internal business purposes, but it does not cover a managed service offered to others, and Community edition scope should be confirmed against your own use. Check the license terms and the queue mode documentation with n8n before you size the deployment.
Moving Zapier Tables data into Baserow step by step
This sequence moves lookup lists, queues and small datasets out of Zapier Tables and into a self-hosted Baserow database, with n8n workflows repointed to the new tables and a parallel run to confirm the data matches before the old tables are retired.
Inventory the Zaps and tables that use Zapier Tables
Start by listing every table, every Zap that reads or writes it, and the fields each step touches. If your account is on a Team or Enterprise plan, export the Zap workflows as JSON from Zapier's import and export feature; the file is an inventory of steps and mapped fields, not a data backup, and it does not carry Tables records. Owners or super admins can export Zaps from all users in the account, which Zapier sends by email from Settings, Security and data. Confirm with Zapier which plan and role you need for this export in your account. The output is a spreadsheet or document that maps each Zapier Table to the Zaps that depend on it.
Export table records from Zapier Tables
Export each Zapier Table's records as CSV or JSON so the data leaves Zapier in a format Baserow can import. Because the Zap JSON export does not include table records, this step is separate from the workflow inventory. Check that row counts in each export match the counts shown in Zapier before you move on. Keep the exports in a controlled location on your own servers, since they may contain operational or personal data. The output is one dated file per table with a recorded row count.
Create Baserow tables and field types
On your self-hosted Baserow instance, create one table per Zapier Table and define each field with a type that matches the stored values, such as text, number, date, single select or link to another table. Recreate the relationships that Zapier Tables used for lookups as link-to-table fields where your data needs them. Confirm that the table and field count matches your inventory and that no table name collides with an existing one. The output is an empty set of Baserow tables with a documented field map.
Import records into Baserow
Import each exported file into its matching Baserow table using the CSV, Excel, XML or JSON importer. Map each source column to the field type you created in the previous step and review date and number formats before you confirm the import, because a mismatch here is the most common source of silent errors. Do the import on a test instance or a separate table first if your data is sensitive or large. The output is populated tables whose row counts match the source exports.
Rebuild lookups, queues and filters
Recreate the logic that Zapier Tables handled implicitly. Lookups can move into n8n nodes that query Baserow by row filter, or into Baserow grid views with filters and sorts that give operators the same subset of data. Queues can be modeled as a table with a status field that workflows update as items are claimed and completed. Check each rebuilt lookup against a sample of known inputs and expected outputs. The output is a short list of which Zap logic now lives in n8n and which in Baserow views, each tested against a sample.
Repoint Zap steps to n8n nodes
Build the workflows in self-hosted n8n that replace the Zaps, using the Baserow node or HTTP Request node to read and write the new tables. Recreate every app connection and credential in n8n, because connections are not carried over from Zapier. Re-create any webhooks with new URLs and update the systems that call them. If you run n8n in queue mode, make sure the encryption key is shared with all workers and webhook processors so they can read stored credentials. The output is a set of n8n workflows, each linked to the Baserow table it uses, with credentials tested.
Run both systems in parallel and reconcile counts
Keep the Zaps and the n8n workflows running side by side for a period you agree on with the process owners. Compare row counts and sampled records between Zapier Tables and Baserow at set points, and log every difference with its cause. Confirm that n8n executions match the Zap runs for the same inputs. Do not let both systems write to the same live queue at once without a clear rule, or you will create duplicate work. The output is a reconciliation log showing matching counts and a list of resolved differences.
Cut over and decommission Zapier Tables
When the reconciliation log is clean and the process owners sign off, turn off the Zaps, switch callers to the n8n webhooks, and make Baserow the system of record. Keep a final export of the Zapier Tables data and the Zap JSON inventory in your retention store before you delete anything in Zapier. Confirm that no Zap still reads or writes a Zapier Table, and then remove the tables. The output is a cutover record and an archived copy of the final Zapier data.
Questions buyers ask before replacing Zapier Tables
What drives the cost of self-hosting Baserow and n8n, and what is one-time versus recurring?
The main costs are the infrastructure you run, the people who build and operate it, and any paid licenses you choose. Baserow's self-hosted Community code is MIT licensed, but Premium, Advanced and Enterprise licenses are paid and an instance can use only one license type, according to Baserow's self-hosted license documentation. n8n's Community edition is free to self-host, while its Business and Enterprise editions are paid, and its Sustainable Use License limits use to internal business or non-commercial purposes. One-time costs are the initial build, data migration and workflow rebuild. Recurring costs are hosting, PostgreSQL and backups, upgrades, monitoring, and support. Ask any quote to separate these lines, and to show which license type each product needs for your user count and features.
How long does a Zapier Tables migration take, and what makes it longer?
The timeline depends mainly on how many tables and fields you move, how many Zaps read or write them, and how much logic must be rebuilt in n8n. Zapier's pricing page lists up to 100 fields per table and record limits per account, so the record count and field types affect import effort. Baserow's CSV, Excel, XML and JSON import, listed on its pricing page, covers many simple tables, while complex relationships and formulas need manual rebuilding. Credential setup, webhook changes and parallel running during cutover also add time. There is no supplied duration for this work, so ask for a written scope that lists each table, Zap and integration, and agree the timeline in that document before work starts.
Can our own team migrate Zapier Tables without outside help?
Yes, a team with Linux, Docker and database experience can run the move itself, but the work is more than importing data. Your team must inventory Zaps that touch Tables, recreate app connections and credentials in n8n, rebuild automations, and test each flow after cutover. Zapier's export of Zap workflows is JSON and only available on Team and Enterprise plans, so it serves as an inventory rather than an import file for n8n. Consider outside help if you lack staff for the rebuild, need validated backups before go-live, or must document controls for an assessment. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your infrastructure under a written, fixed scope.
What does a self-hosted Baserow and n8n setup require from our infrastructure team?
Plan for PostgreSQL, a container platform, backups and a regular upgrade routine. Baserow's Docker image runs all services in one container with an internal PostgreSQL and Redis by default, but Baserow highly recommends an external PostgreSQL for production. Baserow also documents Docker Compose with separate backend and web-frontend images, and Kubernetes with Helm for horizontally scaled deployments. n8n documents Docker Compose and major cloud providers, and queue mode needs Redis and PostgreSQL with workers that share the main instance's encryption key. Your team must also manage TLS, secrets, monitoring and access control. Confirm each component against the current installation documentation for the versions you choose.
Do Baserow record limits apply to a self-hosted installation?
The limits on Zapier's pricing page apply to Zapier Tables, not to Baserow's software. Zapier lists 2,500 records per account on Free, 100,000 on Pro and 500,000 on Team, with Enterprise limits by quote. Baserow's cloud pricing lists a Free plan with 3,000 rows per workspace, which applies to Baserow Cloud, not to a self-hosted instance. Self-hosted capacity depends on your PostgreSQL sizing, hardware and storage, which your team controls. Confirm with Baserow's documentation for your edition and license whether any row or seat limits apply to your installation, and test performance with your own record volume before cutover.
Which Baserow license type do we need to enable single sign-on?
Single sign-on requires the Advanced or Enterprise license with an activated license. Baserow's SSO documentation lists SAML, OAuth 2.0 providers such as Google, GitHub and GitLab, and generic OpenID Connect on those plans. Premium, which assigns seats manually, does not include SSO according to the same documentation. Because an instance can use only one license type, choose the type that matches your user count and identity requirements before you deploy. Baserow's pricing page lists Advanced at $18 per user per month billed yearly for cloud, which is a cloud price and does not set self-hosted license cost. Ask Baserow for a self-hosted quote covering your user count.
How do n8n workflows read and write Baserow tables during the move?
During the move, n8n workflows can call Baserow's API, which is headless and API first, so both systems can run in parallel. Your team can point a workflow at the new table, write to both platforms for a validation period, then switch reads once the data matches. Baserow's import tools handle data copy, but formulas, lookups, rollups, automations and interfaces do not move automatically. n8n's Community edition counts workflow runs without a per-task fee, and its SSO and environments features are paid. Test credentials, rate limits and error handling in a staging instance before cutover, and keep the Zapier flows active until verification completes.
Can we keep Zapier Tables data inside our own network after the move?
Yes, self-hosted Baserow and n8n run in your own infrastructure, so table data, credentials and run logs stay on servers you control. Zapier Tables is a hosted service, so its records sit with Zapier. After migration, your team is responsible for network access, encryption at rest, backups, patching and access reviews. n8n's queue mode requires the encryption key on every worker, so protect that key as a high-value secret. Confirm your data residency and retention requirements with your compliance lead, since self-hosting shifts those controls to your organization. DeployOpen prepares systems, controls and evidence for compliance assessments, but auditors and certification bodies issue any reports.
What you take on when the tables move in-house
Moving from Zapier Tables to self-hosted Baserow shifts operations to your team. Zapier runs the storage, backups and upgrades for you; with Baserow, you own them. Plan for PostgreSQL operations first, because Baserow's Docker image runs an internal PostgreSQL and Redis by default, and Baserow highly recommends an external PostgreSQL for production. Decide who manages that database, how it is backed up, how point-in-time recovery is handled, and how restores are tested. Backups of the database and of Baserow's attachment storage must both be in your plan, since losing either one breaks the tables.
Upgrades are the second recurring task. Baserow published 2.4.1 on October 13, 2026, following 2.4.0 on September 30, 2026, so set up a process to track the Baserow GitHub releases, test each release against a copy of your data, and schedule the upgrade window. The same applies to n8n, whose workflows will read and write these tables. Access control also moves to you: decide who holds admin rights on the instance, how users are provisioned, and whether single sign-on is needed. Baserow SSO requires an activated Advanced or Enterprise license, so confirm which license type fits before you rely on it.
Licensing is the last check. Baserow's core features are under the MIT License, but premium and enterprise features are excluded from that grant, and a self-hosted instance can use only one paid license type. n8n is under the Sustainable Use License, which permits use for your own internal business purposes, so reading and writing Baserow tables from n8n inside your organization generally fits that grant. Have counsel confirm that your intended use, including any work for clients or other organizations, matches the license terms, and confirm which n8n features you need, since SAML and environments with Git sit in the Business and Enterprise plans. Compliance outcomes depend on your controls and an independent assessment, not on the software choice alone.
How DeployOpen scopes and delivers a Zapier Tables replacement
DeployOpen plans, implements and hands over a self-hosted Baserow database in your own infrastructure, with n8n workflows reconnected to it. We start from a written scope that lists the tables, record volumes and workflows to move, so the work and its deliverables are agreed before any build begins.
How we scope
- Inventory every Zapier Tables table, its fields, record count and the Zaps that read or write it.
- Confirm where Baserow will run, including cloud account, data center or air-gapped network, and which PostgreSQL service backs it.
- Agree in writing which license tier, identity integration and cutover window the engagement covers, since engagements are fixed-scope.
How we build
- Deploy Baserow with Docker Compose or Helm, using an external PostgreSQL instance for production as the vendor recommends.
- Recreate tables, field types and access rules, and import data from CSV, Excel, XML or JSON exports where Zapier Tables allows it.
- Rebuild the lookup and queue workflows in n8n, test each read and write path, and document the credentials and encryption key handling.
How we hand over
- Deliver the workflow and table inventory, configuration records and a runbook for operators in your team.
- Walk through a parallel-run and cutover plan so that Zaps are switched off only after the n8n flows pass testing.
- Document the record counts and checks used to confirm that migrated data matches the source before retiring Zapier Tables.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrade planning covers Baserow releases and n8n versions, applied in your environment on a schedule you approve.
- Ask for the support scope, response expectations and upgrade responsibilities in the written quote before work starts.
