Claris FileMaker vs Baserow: which to choose

When FileMaker fits and when a self-hosted Baserow fits better

If your renewal is driven mainly by a per-user price change or a data residency requirement, and your FileMaker solution is a moderate set of tables with forms and reports that users reach through the FileMaker client, a self-hosted Baserow is worth a serious evaluation. If your solution depends on heavy scripting, custom print layouts, plug-ins or native desktop and mobile clients that your staff use every day, FileMaker usually remains the lower-risk choice for now. The decision turns on three things: how many layouts and scripts must be rebuilt, whether users need native clients, and how many people pay a seat.

Start by inventorying the solution. Count the layouts, scripts and calculation fields, and mark which ones drive business logic rather than presentation. Baserow rebuilds screens in its application builder and replaces scripts with automations, so each script with branching, looping or external calls becomes design and testing work. Confirm with your own developers and Baserow's current documentation which of your features map cleanly, because a solution with many unique layouts costs more to rebuild than one with a few shared ones. Also check whether your users rely on the FileMaker client, since Baserow works in the browser and does not need a client app installed.

Then compare the seat count honestly. Under FileMaker Cloud, the cost follows the number of named users and any minimum user count the plan requires, so the bill rises with every person added. Under self-hosted Baserow, the open-source edition under the MIT License carries no license fee, while the Premium, Advanced and Enterprise license types are priced separately and each instance uses only one license type. Ask your vendor and Baserow to quote the same user count, and include the PostgreSQL hosting, the people who operate the instance and the rebuild effort, because those costs do not appear on a license invoice.

Which scenarios favor FileMaker and which favor Baserow

This table compares common situations where FileMaker or self-hosted Baserow is the stronger fit, with the reason for each. Read each row against your own solution: the more rows that match your environment, the clearer the answer. Most teams find that the deciding factors are scripting depth, client app needs and residency rules rather than table count.

Scenario	Better fit	Reason
Deeply scripted solution with many layouts	FileMaker	Scripts, custom layout logic and client-side behavior have no direct one-to-one equivalent in Baserow. Expect a rebuild effort, not a copy.
Browser-only team with no native client needs	Baserow	Baserow runs entirely in the browser, so users do not install or maintain desktop clients.
Data residency mandate for self-hosted records	Baserow	Self-hosted Baserow keeps tables, attachments and access data on servers you choose. Confirm your hosting region and backup locations with your compliance team.
Offline or native client use in the field	FileMaker	FileMaker has native and mobile clients for offline work. Confirm that your offline workflows are covered before choosing Baserow, which depends on a live browser connection.
Small set of tables with portals and automations	Baserow	Linked records, a grid-based portal equivalent and automations cover small relational models. Confirm each portal and script you rely on maps to a Baserow feature.
Heavy reliance on custom privilege sets and security scripts	FileMaker	FileMaker privilege sets are tightly coupled to scripts and layouts. Baserow permissions are simpler, so confirm the access model meets your requirements.

Where your records and access rules live under each option

Records, attachments and access rules sit in different places under FileMaker Cloud, FileMaker Server and self-hosted Baserow. The cards below cover where data lands, how the Baserow deployment is shaped, and which identity and audit features depend on the license you choose.

Data location under FileMaker Cloud and Server

FileMaker Cloud runs in infrastructure operated by Claris, so the hosting location and operator are set by the vendor rather than by your team. FileMaker Server runs on machines you control, which keeps files in your data center or cloud account. Ask Claris in writing where FileMaker Cloud hosts your files, backups and logs, and which subprocessors touch them. Confirm the same for any Server deployment you plan to keep.

Self-hosted Baserow in your own account

Self-hosted Baserow runs in your cloud account, on-premises servers or air-gapped network, so tables, attachments and workspace metadata stay where you put them. Your team, not a vendor, decides backup location, encryption at rest and network paths. Map each data class, including attachments and audit exports, to a storage location before you copy records across.

Single-container Docker versus external PostgreSQL

The baserow/baserow image runs all services in one container with an internal PostgreSQL and Redis by default, which suits evaluation. Baserow highly recommends an external PostgreSQL for production, so backups, restores and patching can follow your database standards. Decide who owns that database, how it is backed up, and whether it sits inside your existing PostgreSQL estate.

Docker Compose or Kubernetes for scale

Baserow documents Docker Compose with separate backend and web-frontend images, and Kubernetes with Helm for horizontally scaled deployments. Compose fits a single host with a defined upgrade window. Kubernetes fits teams already operating a cluster with their own ingress, secrets and monitoring. Confirm which topology your platform team supports before you size storage for attachments.

SSO and license tier

Baserow single sign-on covering SAML, OAuth 2.0 providers and generic OpenID Connect requires the Advanced or Enterprise plan with an activated license. A Premium instance does not include this, so FileMaker accounts that rely on directory sign-in need a plan decision first. Ask Baserow which license type covers your user count before you design the access model.

Audit logs and compliance evidence

Baserow lists audit logs among Advanced features on its pricing page, so confirm whether your chosen license exposes the log detail you need. FileMaker access history depends on how Server or Cloud is configured. Neither product issues compliance evidence on its own. Independent auditors and certification bodies assess your controls, so agree the log retention and review process with them early.

How Baserow's open core and license types differ from FileMaker's sales model

Baserow's core is open core. All features that are neither premium nor enterprise sit under the MIT License, which permits commercial and private use. An organization can install that edition on its own servers without buying a license, and the code can be inspected, forked and modified. The boundary matters: premium and enterprise features are excluded from the MIT grant, so the open-source edition does not include everything the paid tiers offer.

Covered by MIT: the core spreadsheet database, tables, views, forms and API features that fall outside the paid tiers.
Excluded from MIT: premium and enterprise features, which require a license key.
Self-hosting cost: the software itself carries no license fee for the core edition, but servers, PostgreSQL, backups and administration still cost money.
Source access: the code is public in the Baserow repository, which supports internal review.
Boundary check: confirm which specific features your team needs are in the MIT scope before assuming the free edition covers them.

Ask Baserow to map each feature you rely on to its license tier in writing before you commit to a deployment design.

What drives the total cost of each option

Total cost for FileMaker and self-hosted Baserow splits into software fees, infrastructure, rebuild effort and people. Each component has a different payer, a different recurrence and a different driver, so compare them line by line rather than as a single license figure.

FileMaker licenses and user minimums

FileMaker Cloud is sold as per-user plans, and FileMaker Server is licensed separately for self-hosting. Ask the vendor or reseller whether the quoted plan carries a minimum user count, how many named users you need and whether licenses renew annually. Recurring fees scale with headcount, so a solution used by a few staff and one used by hundreds produce very different totals. Confirm the current terms in writing, because they change.

Baserow edition and seat model

The open-source edition of Baserow is licensed under the MIT License, so the software itself carries no license fee. Paid self-hosted features follow a separate model: Premium assigns seats to named users, Advanced grants access to users on the instance, and Enterprise is priced through sales. Baserow's cloud pricing page lists per-user rates for comparison, but self-hosted license prices must come from Baserow. Ask which license type fits your user count, since an instance can use only one type.

PostgreSQL, servers and backups

Baserow's Docker image runs an internal PostgreSQL by default, but Baserow highly recommends an external PostgreSQL for production. That means you pay for database hosting, compute, storage, backups and monitoring in your own cloud account or data center. These costs recur monthly and grow with record volume, attachments and the number of concurrent users. Ask your team to size them from expected records and attachment storage, not from user count alone.

Rebuilding layouts and scripts

This is usually the largest one-time cost. FileMaker layouts and scripts do not transfer, and they must be rebuilt in Baserow's application builder and automations. Baserow's Airtable importer does not carry over automations or interfaces, which shows how much logic must be recreated by hand. Effort rises with the number of scripts, custom layouts and calculation fields. Request a quote that lists each screen and script as a separate line item.

Data export and relationship mapping

Moving tables, relationships and container contents out of FileMaker is one-time work with a recurring test cycle. Container fields and relationships need explicit mapping, and each table often needs cleaning before import. Ask for a fixed-scope estimate covering export, validation, reconciliation and a rollback plan, and confirm whether attachment migration is included.

Training, support and upgrades

Users must learn the browser interface, and administrators must learn Docker or Kubernetes operations, backups and upgrades. Training is largely one-time, while patching, upgrades and incident response recur. Decide whether your own staff, a retained support provider or a mix will carry them. Ask any provider for the scope of ongoing support, response expectations and who owns upgrades of Baserow and PostgreSQL.

What moving a FileMaker solution to Baserow involves

This sequence turns a FileMaker solution into a Baserow build that keeps the same data, relationships and business rules, and it ends with users confirming the new system works for their daily tasks.

Inventory tables, layouts and scripts
The team lists every FileMaker table, relationship, layout, script, value list and access privilege, then records which screens and scripts users rely on each day. A developer who knows the solution, paired with a business owner, usually does this work. It is done when every table and every script has a row in a shared inventory with an owner and a decision: move, rebuild, retire or keep in FileMaker until the cutover.
Export each table to CSV or Excel
Each FileMaker table is exported on its own, using CSV or Excel, because FileMaker exports data one table or found set at a time. The export covers field values only, so layouts, scripts, formatting and calculated logic stay behind and must be documented from the inventory. The check is a row count and a spot check of key fields for each table against the live FileMaker file, with the results logged.
Handle container field contents
Container fields hold images, PDFs and other files inside FileMaker, and a CSV export does not carry them over automatically. The team extracts these files separately, names them consistently and maps each one to its record, then uploads them to Baserow file fields during import. Confirm the approach with a sample record set first. It is complete when a sampled set of records opens with the correct attachments in Baserow.
Import tables and recreate relationships
The tables are created in Baserow, the data is imported, and the link-to-table fields are rebuilt to match the FileMaker relationships, including which side holds the link. Calculated and summary fields from FileMaker are recreated by hand, since the Airtable importer does not carry over formula, lookup or rollup fields, and the same limit should be assumed for any tool-to-tool import. The check is that records link correctly across tables and totals match the FileMaker source.
Rebuild screens in the application builder
FileMaker layouts are rebuilt as pages in Baserow's application builder or as grid and form views, matched to the screens recorded in the inventory. Browser access replaces the FileMaker client, so layout behavior that depended on the desktop client needs to be re-tested in the browser. Field-level and table-level permissions are set to match the access rules recorded earlier. It is done when each inventoried layout has a Baserow equivalent that a named user has reviewed.
Replace scripts with automations
Each FileMaker script is rewritten as a Baserow automation, a workflow triggered by a record change, a schedule or a button, or as a manual process where the logic is too specific to automate. Airtable automations do not carry over, and FileMaker scripts have no automatic conversion, so this step is manual work by a builder who understands both systems. The output is a tested list of automations, each traced back to the original script it replaces.
Test with users in parallel
Users run their daily tasks in the new Baserow build while FileMaker stays live, and they compare results record by record for a defined period agreed before testing starts. Defects, missing fields and unclear screens are logged, fixed and retested. Parallel running is complete when the agreed test cases pass and the business owner signs off the cutover date in writing.
Train users and cut over
Users are trained on the Baserow screens, views, filters and automations that replace their FileMaker workflows, and written guides are shared for the tasks that changed. The final data load is run, FileMaker is set to read-only, and the old file is archived under the organization's retention rules. The cutover is complete when users work only in Baserow and the archive is verified as openable and searchable.

What changes for developers and power users after the move

The biggest shift is that FileMaker's scripts and layouts do not carry over as they are. In FileMaker, a developer builds screens in Layout mode, places fields and buttons, and writes logic in scripts with script steps that run on the server or the client. In Baserow, the equivalent work is split across the application builder, which assembles pages and forms from data sources, and automations, which trigger actions when rows change or on a schedule. Baserow is also headless and API first, so anything a power user builds can be reached through its REST API, which changes where business logic tends to live. Before the move, the team should inventory each script and sort it by purpose: data validation, navigation, batch updates, integrations or reporting. Each category maps to a different Baserow feature, and some will need to be rebuilt by hand rather than translated.

The size of the change depends mostly on how much of the solution sits in scripts and client apps. If the database has a modest number of tables, simple relationships, a handful of scripts and users who work in a browser, the change is usually small: data moves over, views and forms are recreated, and a few automations replace the scripts. The change becomes large when the solution relies on calculation-heavy fields, custom privileges set through FileMaker accounts, scripted imports or exports, container field workflows, or on FileMaker Pro or FileMaker Go clients that users depend on daily. In those cases, the team should plan for a rebuild of logic, not a migration of files. The skills required shift from FileMaker scripting and calculation syntax toward relational data design, REST API usage, and familiarity with automation triggers. Confirm with the vendor which automation actions and API capabilities are available in the edition you select, because these vary by plan.

Questions buyers ask before switching from FileMaker to Baserow

What drives the cost and effort of moving from FileMaker to Baserow?

The biggest drivers are how many layouts, scripts and relationships the FileMaker solution contains, how much data sits in container fields, and how many users need to be retrained. Costs fall into a few components: the Baserow license or open-source deployment, PostgreSQL and hosting in your own infrastructure, the rebuild of layouts in the application builder and scripts as automations, data migration, and support. Licensing is a recurring cost on the Baserow side only if you choose a paid self-hosted plan, while the rebuild is one-time. Ask any partner for a quote that itemizes these components against your written scope.

How long does a FileMaker to Baserow migration take?

No fixed duration applies to every solution, so treat any single figure with caution. The length depends on scope: the number of tables and relationships, how many layouts and scripts must be rebuilt, the volume of attachments, and how much testing and user training is required. A small solution with few scripts is far simpler than a multi-department system with custom logic. Ask for a timeline that is tied to a written, fixed scope and to named deliverables.

What does the migration need from our internal team?

Your team needs to supply knowledge of how the FileMaker solution is actually used, including which layouts, scripts and calculations matter and which are obsolete. Someone must own data decisions, such as how to handle container field contents, duplicate records and fields that have no direct Baserow equivalent. You will also need access to the FileMaker database for export, a place to host Baserow with PostgreSQL, and business users available for acceptance testing and training.

Can an internal team migrate from FileMaker to Baserow on its own?

Yes, an experienced internal team can do it, particularly for a simple solution with clean data. The Baserow Airtable importer shows the kind of tooling involved, but FileMaker has no equivalent single-step import, so you would export each table, recreate relationships, rebuild layouts in the application builder and replace scripts with automations by hand. Teams that lack this experience, or that must meet audit or compliance evidence requirements, often bring in an implementation partner for a fixed-scope engagement. Assess your skills against the page on the migration path before deciding.

Does Baserow work offline or as a native desktop client like FileMaker?

No. Baserow is accessed through a web browser, so users do not install a client application as they do with FileMaker Pro. This suits browser-based access and reduces client maintenance, but it means the solution depends on a network connection to your Baserow server. If your users rely on offline work or on native client features, confirm that requirement early and test it against the current Baserow capabilities in your own environment before committing.

Which Baserow license is needed for single sign-on and audit logs?

Single sign-on, covering SAML, OAuth 2.0 providers and generic OpenID Connect, is available on the Advanced and Enterprise plans with an activated license. Baserow's pricing page lists audit logs and role-based permissions for Advanced. The open-source edition under the MIT License does not include these premium and enterprise features. Self-hosted licenses are Premium, Advanced and Enterprise, and an instance can use only one license type, so confirm the exact feature set with Baserow before you plan around it.

When should we choose Grist or the FileMaker cost page instead?

Choose Grist if your FileMaker solution is calculation-heavy and your team is comfortable with Python formulas, since Grist's model differs from Baserow's application builder. Read the sibling comparison of FileMaker and Grist before deciding. Review the FileMaker cost page if your main question is what the current FileMaker licensing costs compared with self-hosted options, as that page covers the cost components in detail. Both choices should follow a clear view of your data, layouts and scripts.

When keeping FileMaker for part of the workload makes sense

A split estate is worth considering when part of the FileMaker solution is simple data capture and reporting and another part depends on scripts, custom layouts and integrations that would take the longest to rebuild. The usual pattern is to move plain tables and their forms to Baserow first, then keep the scripted, calculation-heavy solution on FileMaker until its replacement is ready. This only works if the boundary is drawn on purpose. List every table, layout and script, mark which ones another table depends on, and decide which side owns each record. A table that FileMaker scripts write to on every transaction is a poor first candidate for a move.

Running both systems raises two questions that need written answers before go-live. The first is data sync: will records be copied one way on a schedule, will both systems be writable for the same table, and who resolves conflicts when the same record changes in both places? Two-way sync between a FileMaker file and a Baserow table is custom work, so confirm with your implementation partner whether a one-way export or a scheduled import meets the need. The second is governance: each side has its own accounts, permissions and audit trail. Map which roles can see which records in FileMaker and in Baserow, and confirm how Baserow's role-based permissions and audit logs apply to your edition, since the pricing page lists them for the Advanced plan.

For a parallel test, pick one table, run both systems against a copy for a fixed period, and compare record counts, attachments and calculated values. Record the differences and decide in advance what counts as a pass. Keep the FileMaker licenses running for the overlap, and budget for the people who keep two systems in step during it. Ask for the exit date for each component in writing, so the split does not become permanent by default.

How DeployOpen helps evaluate, implement or migrate

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a FileMaker to Baserow move, we start with a written scope that maps your tables, layouts, scripts and user groups to what Baserow can and cannot carry over.

How we scope

Inventory every FileMaker table, relationship, layout, script and access group before choosing what moves to Baserow.
Agree the scope, deliverables and timeline in writing before any work starts, as most engagements are fixed-scope.
Document which container fields, calculations and scripts need rebuilding, replacing or retiring, so the quote follows from real features.

How we build

Deploy Baserow in your own cloud account, data center or air-gapped network, with an external PostgreSQL for production.
Rebuild tables, relationships and access rules, then recreate the required interfaces in the application builder and automations.
Test imports, permissions and browser access with representative users, and record the results for your review.

How we hand over

Deliver runbooks covering installation, configuration, backup, restore and upgrade steps for your operations team.
Provide user guidance and training material for the layouts and automations that replace FileMaker scripts.
Hand over the written record of what moved, what was rebuilt and what was left behind, so business owners can sign off.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after go-live.
Plan Baserow version upgrades and test them against your tables and automations before they reach production.
Confirm with your team which license type and identity provider settings suit your user count and single sign-on needs.

Claris FileMaker vs Baserow