最近低代码领域有一个消息值得所有用过 Airtable 的团队重视Bending Spoons 正在推进对 Airtable 的收购交易金额约为 22 亿美元。看到这条消息很多开发者和业务负责人的第一反应不是“恭喜”而是三个很现实的疑问我存在里面的业务数据以后会不会受影响免费版会不会被大幅收缩API 会不会被砍掉这不是一个普通的资本新闻。Bending Spoons 过去几年收购并改造过多个知名产品思路非常明确控制成本、提升商业化效率、让产品走向盈利。而 Airtable 则是低代码数据库领域最具代表性的产品之一被很多人当成“表格 数据库 轻量应用平台”在使用。一个讲究精细化运营的买家遇到一个长期依赖免费用户和品牌口碑的 SaaS 产品后续的定价策略、功能取舍和企业服务方向大概率会发生变化。这篇文章不讨论八卦也不做资本分析。我想从开发者的视角把这件事拆成几个技术问题来谈Airtable 到底解决什么问题、本次收购对使用者意味着什么、数据备份和迁移该怎么做、以及当我们把业务系统建在低代码平台之上时怎样才能避免被供应商变化牵着走。1. Airtable 到底是什么先回答“为什么一个表格工具值 22 亿美元”如果只看产品首页很多人会把 Airtable 理解成“更好看的 Excel”。实际上它要解决的问题比电子表格深一层它想让非技术团队也能快速搭建一个结构化的业务数据库并且不需要写一行代码。1.1 表格、数据库与低代码平台的混合体Airtable 的底层是一个云数据库但它的操作界面是表格。传统电子表格擅长自由录入却很难维护数据之间的关系。传统数据库擅长关系和查询但对业务人员来说门槛太高。Airtable 选择了一条中间路线用户看到的是一张张有类型的表背后则是可查询、可关联、可自动化、可编程的数据模型。典型的使用方式是市场团队用它维护内容排期表字段包含标题、平台、发布状态、负责人并通过状态字段驱动自动化提醒。产品团队用它记录用户反馈用关联字段把反馈和具体需求条目连接起来。运营团队把 Airtable 当成轻量 CRM记录客户信息、跟进记录和合同状态。开发团队则会在它之上搭建后台原型用 API 把前端页面连到这些表上。所以在实际项目中Airtable 不仅仅是一个“在线表格”它经常承担着原型阶段的小型业务系统、运营工具的数据中枢、以及跨团队共享的数据集散地。1.2 核心概念Base、Table、Field、View、Automation要理解 Airtable 对开发者意味着什么需要先建立一组核心概念。Base相当于一个应用或一个数据库实例。一个工作区里可以包含多个 Base每个 Base 相互隔离。TableBase 中的一张表等价于关系数据表。表里的每一行是一条 Record。Field字段等价于列。Airtable 支持的字段类型比普通表格更丰富包括文本、数字、日期、单选、多选、附件、关联字段、公式、查找字段等。View视图。同一张表可以有不同的展示方式比如网格视图、看板视图、日历视图、画廊视图。视图不会改变数据本身只改变观察和操作的方式。Automation自动化。用户可以基于触发条件配置动作比如“状态变为已完成时发送 Slack 通知”。这套设计的关键在于数据是有类型的类型之间有约束表之间可以建立关联。这就让它和纯 Excel 拉开了本质差距也让“用 Airtable 搭建应用”成为可能。1.3 它解决了什么问题没有 Airtable 时一个业务团队想建立“数据和流程”的雏形通常只有两个选择用 Excel 收集信息然后由开发重复造后台或者直接上一套重量级业务系统比如昂贵的 CRM、项目管理平台。前者的问题是数据混乱、无结构、无法实时协作后者的问题是周期太长、成本太高、流程大而全但不灵活。Airtable 的切入点是“非技术团队也能建模”。它把数据库的表、字段、关系用电子表格的操作方式表达出来让人在没有开发资源的情况下完成从数据收集到流程管理的跨域。对于开发者来说它降低了业务方反复提需求的频率因为业务人员可以直接调整字段、新增视图、配置自动化同时Airtable 提供 REST API开发者可以拿到 record 数据接入脚本、定时任务或外部系统。但这背后是一笔隐性的技术债你的数据模型、业务流程和协作关系建立在别人家的数据库之上。平台规则一变你所有基于它的流程都有重新评估的成本。2. Bending Spoons 是谁这次收购的底层逻辑Bending Spoons 是来自意大利的动态平台公司多年来以收购成熟产品并做增长和盈利优化著称。它旗下的产品包括远程演示工具、视频制作应用以及之前被收购后调整了商业模式的笔记工具 Evernote。从公开信息可以看到一个明显的思路找到有品牌影响力和用户基础的产品通过优化成本结构、调整定价、强化订阅转化来实现盈利。如果看 Bending Spoons 过往的收购路径再对照 Airtable 的产品特点这次收购大概有三层逻辑。第一Airtable 的产品已经相当成熟。它不是早期创业项目而是拥有大量中型企业用户、成熟 API 体系和丰富生态的 SaaS 产品。收购方不需要从零验证市场重点是怎么提高它的收入和利润。第二Airtable 有典型的“可商业化升级”空间。低代码工具的用户往往从免费版或低价版开始使用随着团队规模扩大逐渐升级。收购方有很强的商业化动力去推动这种升级通过对功能分层和配额设计让更多免费用户转化为付费用户。第三企业级客户是更值得聚焦的群体。Airtable 的价值主要来自企业和团队场景而不是个人记录工具。新的管理团队大概率会把资源集中在大客户、企业权限、安全合规、审计能力上而这些方向必然会有对应的定价变化。从这种思路看Airtable 被收购后最可能发生的变化是商业模式会变得更激进产品功能会倾向于服务企业付费客户免费版和低价版的使用边界会被重新划定。对开发者群体来说最直接的影响并不是“明天就不能用了”而是“未来一年内成本、配额、API 策略都可能会出现变化”。3. 收购之后最现实的三个技术问题没有必要因为一个收购消息就立刻抛弃现有系统但技术负责人应该提前评估三种风险出现的概率。3.1 免费版功能和配额会不会收缩免费版是 Airtable 培养用户习惯的重要入口但也是成本压力最大的部分。从收购方过去调整产品的历史看免费版要么被更严格地限制要么被压缩到小规模试用水平。过去 Airtable 免费版允许用户创建有一定记录数限制的 Base自动化次数也有限。收购后这种配额很可能会进一步收紧比如限制单表记录数、限制附件总存储、降低自动化次数。对个人开发者和早期团队来说这会让“免费使用”变成相对勉强够用的状态。3.2 API 与自动化能力会不会保持API 是 Airtable 除了界面之外最有价值的部分。很多开发者用它做数据中转、脚本来同步、与外部系统集成。API 本身是付费企业客户的重要依赖收购方不会轻易砍掉这项核心能力。但需要注意方向问题API 可能继续存在但访问频率限制、数据量限制、高级 API 功能是否单独定价这些细节可能调整。自动化功能也是同理。Airtable 的 Automation 让不懂代码的人也能搭建流程比如“新记录创建后发送邮件”。如果这套能力被迁移到更严格的套餐之内相当一部分团队的工作流都要跟着调整。3.3 定价与结算方式变化SaaS 公司在被收购或融资后调整定价并不罕见。Airtable 过去按席位计费收购后可能会出现套餐合并、功能拆分、升级要求更多的付费层级。有一个容易被低估的问题如果你在不同 Base 里已经积累了大量数据而这些数据在免费版配额收紧后“读不出、导不出”迁移成本会急速上升。所以这里有一个务实的判断不要在收购完成之后再准备备份而是在消息刚落地时就把数据主动权牢牢握在自己手里。4. 作为开发者现在应该做什么数据主动权是底线面对平台型 SaaS 的收购最不该做的是“什么也不做等着看”。对技术人员来说有一条底线原则你的业务数据不能成为供应商单方面决策的筹码。备份和迁移能力是保留选择权的必要条件。4.1 盘点现有 Base 和自动化流程第一步是先搞清楚你所在团队到底在 Airtable 上放了什么。你需要把每个工作区、每个 Base 列出来确认其中哪些是测试数据哪些是真实业务数据。对真实业务数据要弄清楚它的更新频率、负责人、依赖方。与此同时把已经配置的 Automation 列出来包括触发条件、动作类型、使用频率。很多团队给自己搭建了几十条自动化平时没感觉一旦平台配额收紧这些流程会集体面临失效风险。建议用一张表格管理这些信息资产类型数量依赖方风险等级业务 Base若干运营、市场、销售高自动化流程若干团队内部通知中外部 API 集成若干自研系统高表格附件素材若干内容运营中4.2 把关键数据导出备份导出动作不应该等到“平台不能用了”才开始而应该作为常态化操作。Airtable 界面本身支持导出 CSV但只能一次导一张表。如果你有几十张表手动导出会非常耗时。更合理的方案是调用官方 API把每个 Base 中的所有表、所有字段、所有记录批量拉到本地。这个问题后面会用完整代码演示。4.3 准备迁移预案备份是第一步迁移是更复杂的工程。“迁移”不等于“把 CSV 导出来”它意味着你要在另一个平台上重建字段类型、关联关系、附件存储、用户权限甚至要重写自动化流程。如果这个平台还涉及外部 API 调用那还要更新所有集成的地址和密钥。迁移预案至少要包含三件事目标平台技术评估、数据模型映射方案、以及切换顺序。切换时建议先切一个低风险 Base 做验证再扩大到完整业务线不要一次性把所有团队搬到新平台。4.4 技术评估模型做评估时我建议从五个维度打分数据导出能力是否支持全量导出导出格式是否完整。API 开放性是否有稳定的 REST APIToken 管理是否灵活。自动化能力是否支持触发器、条件判断和 Webhook。部署方式SaaS、私有化、还是开源自托管。成本结构按席位付费还是按用量付费数据量增长后成本如何变化。当你把 Airtable 和候选方案放进同一个框架里比较就会发现“要不要离开 Airtable”不是一道选择题而是一道风险管理题。你的目标不是立刻搬家而是让搬家变得在任何时候都可选。5. Airtable API 实操如何把数据备份到本地无论你最后决定继续使用 Airtable还是准备迁移到其他平台“把数据备份到本地”都是一项必须掌握的基础能力。5.1 环境准备本文的备份脚本使用 Python 3 和 requests 库。你只需要准备三样东西一个 Airtable 账号并且对这个 Base 有读权限。一个 Personal Access Token权限至少包含data.records:read和schema.bases:read。操作系统的 Python 3 环境。生成 Personal Access Token 的操作路径是进入 Airtable 账号在 Personal Access Token 页面创建 Token然后勾选需要访问的 Base 和对应权限。注意不要让 Token 泄露到代码仓库里建议通过环境变量注入。安装依赖pip install requests5.2 用 API 读取单表数据先从一个最小调用开始理解 Airtable API 的返回结构。import os import requests BASE_ID appYourBaseId TOKEN os.environ.get(AIRTABLE_TOKEN, patYourToken) TABLE_NAME task url fhttps://api.airtable.com/v0/{BASE_ID}/{TABLE_NAME} headers {Authorization: fBearer {TOKEN}} resp requests.get(url, headersheaders) print(resp.status_code) data resp.json() for record in data.get(records, []): print(record[id], record[fields])返回结果最常见的形态是{ records: [ { id: recXXX, createdTime: 2025-01-01T00:00:00.000Z, fields: { name: 完成备份, status: 进行中, owner: 张三 } } ] }这里最需要注意的是分页。Airtable API 单次最多返回 100 条记录当数据量超过这个上限时响应中会出现offset字段。你需要把offset带到下一次请求的参数里直到返回结果中没有offset为止。5.3 批量导出整个 Base 的完整脚本下面这个脚本分三步先读取整个 Base 的 schema拿到所有表名再对每个表做分页拉取最后落成本地 CSV 文件。import csv import os import time from urllib.parse import quote import requests BASE_ID appYourBaseId TOKEN os.environ.get(AIRTABLE_TOKEN, patYourToken) API_URL https://api.airtable.com/v0 HEADERS {Authorization: fBearer {TOKEN}} # 1. 获取 Base 中的所有表 meta_url f{API_URL}/meta/bases/{BASE_ID}/tables resp requests.get(meta_url, headersHEADERS) resp.raise_for_status() tables resp.json().get(tables, []) # 2. 遍历每个表带分页读取全部记录 for table in tables: table_name table[name] records [] offset None while True: params {pageSize: 100} if offset: params[offset] offset url f{API_URL}/{BASE_ID}/{quote(table_name)} page_resp requests.get(url, headersHEADERS, paramsparams) page_resp.raise_for_status() page_data page_resp.json() records.extend(page_data.get(records, [])) offset page_data.get(offset) if not offset: break # 3. 收集所有字段写入 CSV field_names set() for record in records: field_names.update(record.get(fields, {}).keys()) field_names sorted(field_names) file_name f{quote(table_name, safe)}.csv quote_safe __ with open(file_name, w, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnames[record_id] list(field_names)) writer.writeheader() for record in records: row {record_id: record[id]} fields record.get(fields, {}) for name in field_names: value fields.get(name, ) if isinstance(value, (list, dict)): value str(value) row[name] value writer.writerow(row) print(f已导出表: {table_name}, 记录数: {len(records)}, 文件: {file_name}) # 避免请求过快触发限流 time.sleep(0.2)脚本中的关键点有三个通过meta/bases/{BASE_ID}/tables获取表清单通过offset处理分页通过quote()对表名做 URL 编码避免表名含空格时请求失败。如果你的表名比较特殊也可以不依赖 meta 接口而是把要导出的表名写在一个列表里。这样更可控。TABLE_LIST [task, member, comment]5.4 如何验证备份结果备份文件生成后不要只看“文件存在”就认为成功。建议做三件事检查 CSV 是否包含预期的记录数和 Airtable 界面右下角显示的行数比对。检查字段是否完整特别是附件字段、关联字段和公式字段。随机抽查几条记录确认关键业务字段没有被str()变成不可读的内容。关联字段在 CSV 中会显示为类似[recXXX, recYYY]的字符串这是正常现象。但如果你准备迁移到另一个数据库系统这种字符串需要拆解成中间关联表而不是直接导入目标表。5.5 附件和文件数据怎么处理CSV 无法保存附件本身。如果你的 Base 中使用了附件字段备份时需要额外处理读取附件字段中的 URL把文件下载到本地再保存一份“表名-记录ID-附件URL-本地路径”的映射清单。可以用下面的思路实现import requests from urllib.parse import urlparse def download_attachment(url, save_dir): resp requests.get(url, streamTrue) file_name urlparse(url).path.split(/)[-1] file_path os.path.join(save_dir, file_name) with open(file_path, wb) as f: for chunk in resp.iter_content(chunk_size8192): f.write(chunk) return file_path附件 URL 通常带有时效性所以这类备份要尽快执行。6. 替代方案与自建路线对比如果你判断 Airtable 未来有可能持续涨价或收紧免费版那现在选择一个备选平台就是合理的技术决策。低代码和数据库领域目前有不少替代方案但并没有一个方案能 100% 对等替换 Airtable。你需要明确自己的核心场景再做取舍。6.1 开源自托管方案NocoDB、Baserow、TeableNocoDB、Baserow 和 Teable 是几款比较有代表性的开源低代码数据表格工具。它们的界面风格都能做到接近 Airtable而且可以部署在自己的服务器上数据由自己掌控。NocoDB 的特点是“数据库视图化”它可以直接连接 MySQL、PostgreSQL 等已有数据库把现有数据表包装成类似 Airtable 的界面。对于已经拥有数据库的技术团队来说这是一个迁移成本很低的方案。Baserow 更偏向从零搭建的云表格平台支持看板、日历、表单等视图插件机制也比较清晰。Teable 是近年社区关注度较高的开源项目主打高性能和插件化对开发者比较友好。选择这类方案的风险点并不是功能不够而是工程化成本。自托管意味着你要自己处理服务器、数据库、备份、升级、安全和可用性。如果团队只有三五个人也不太擅长运维直接自托管反而会变成新的负担。6.2 关系型数据库 管理后台如果你的业务数据已经相当结构化那另一个思路是彻底放弃低代码平台直接在 PostgreSQL 或 MySQL 上建模再配一个后台管理界面比如 Supabase。Supabase 的定位是开源 Firebase 替代品底层使用 PostgreSQL自带认证、实时订阅、Storage 和 REST API。对于开发者来说这意味着所有需求都能用 SQL 和代码来满足没有平台配额的限制数据完全握在自己手里。这种方案的真实门槛是开发工作量。云表格平台最大的优势是业务人员可以自己改字段、新建视图而一旦转移到数据库加后台这些操作都要通过开发来实现。如果你需要频繁支持业务方的临时改动纯技术方案并不一定更省力。6.3 商业替代产品Notion、ClickUp、Monday很多人会把 Airtable 的替代品等同于 Notion但这两者并不完全一样。Notion 的强项是文档、知识库和页面组合数据库能力更适合轻量级内容管理。Airtable 的强项是结构化数据和自动化流程。ClickUp 和 Monday 同样是项目管理和工作流工具适合团队任务追踪但在自由数据建模和 API 深度上各有边界。它们对 Airtable 的替代性取决于你是否依赖“自定义字段类型、跨表关联、外部 API 读写”这类高级能力。6.4 替代方案对比方案数据控制权部署方式上手成本API 能力适用场景Airtable低SaaS低强非技术团队快速搭建NocoDB高自托管中中已有数据库需要可视化界面Baserow高自托管/云中中轻量表格协作和自动化Teable高自托管中中开发者友好的低代码平台Supabase 自研后台高自托管/云高强技术团队长期自建Notion低SaaS低弱文档和轻量数据库7. 迁往开源低代码平台的实践要点如果你的评估结论是“继续用 Airtable 的风险太高”那实战迁移一般会走三条路径。这里以 NocoDB 为例说说字段映射和导入数据时最容易踩的坑。7.1 数据模型映射Airtable 和 NocoDB 的数据模型并不完全一致。迁移的第一步是在目标平台手动建立表结构而不是直接导入 CSV。因为 CSV 只保留字段名和值没有字段类型信息。常见映射可以参考下表Airtable 字段类型NocoDB / 开源平台映射注意事项Single line textSingleLineText直接映射Long textLongText换行符需要检查NumberNumber核对小数位和精度Date / Created timeDateTime注意时区Single selectSingleSelect需要提前创建选项Multiple selectMultiSelect选项值要一一对应AttachmentAttachment需要单独上传附件Link to another recordLink / Rollup必须拆成关联表FormulaFormula / 不迁移公式结果可导出为静态值如果是自建 PostgreSQL建议直接把原始数据导入临时表再通过 SQL 转换。不要把 CSV 的字符串数组字段直接塞进关联表。7.2 导入数据的执行顺序迁移操作要合理排序。先建字段结构再导入基础表再建立关联关系最后才是配置视图和自动化。具体顺序是在目标平台创建所有表字段类型尽量一次定义完整。先导入没有外键依赖的基础表例如用户表、分类表。再导入有引用关系的业务表例如任务表、订单表。建立字段关联后逐条核对引用是否断裂。最后创建视图和自动化流程。如果在导入时发现选项字段的值对不上先统一枚举值再执行导入避免产生脏数据。7.3 常见问题与排查思路下面是迁移和备份过程中比较常见的几类问题问题现象可能原因排查方式解决方案API 返回 401Token 权限不足或已过期检查 Token 状态和作用域重新生成 Personal Access Token勾选需要的 Base 和 data.records:read 权限API 返回 404Base ID 错误或表名不准确检查 URL 中的 Base ID 和表名通过 meta 接口确认表名对表名做 URL 编码API 返回 429请求频率过高查看响应头中的速率限制信息在请求之间增加 sleep降级为逐表导出CSV 字段错位字段顺序不一致或包含换行用 pandas 读取并检查列数统一使用 DictWriter 按字段名写入附件无法打开Airtable 附件 URL 有时效测试下载链接是否有效尽快下载并转存到本地对象存储导入后关联丢失关联字段被当作字符串导入检查目标表关联字段的值先建中间表按记录 ID 重建外键关系自动化流程失效触发器类型或平台语法不同逐个对比原流程的触发条件在目标平台用最小场景重新配置再做全量切换8. 工程建议低代码平台选型的通用判断框架Airtable 被收购只是一个导火索。真正值得思考的是团队以后选择低代码平台时应该用什么样的标准来避免“被平台绑架”。8.1 数据所有权和导出能力优先任何平台都可以被列为首选前提是它不限制你离开。评估平台时第一指标不是功能丰富度而是“导出能力”和“数据格式开放度”。如果某个产品允许你随时完整导出所有数据包括字段类型、关联关系、附件文件和操作日志它的供应商风险就相对可控。如果导出时需要联系客服申请、或者只能导出部分摘要数据那它的后期替换成本会高到让团队失去选择权。8.2 API 是长期依赖的关键对开发者来说低代码平台的可编程边界非常重要。你需要确认它是否提供稳定的 REST API 或 GraphQL API、Token 管理体系是否完善、是否有 Webhook、是否支持服务端集成。如果一个平台的 API 只能读数据不能写数据或者写数据时有很严格的频率限制那就不能把它当作业务系统底座来使用。API 的开放程度决定了这个平台未来能不能承载自动化、数据同步和二次开发。8.3 关注供应商商业模式变化一个平台的定价策略、免费版策略、商业化节奏会在长期使用中持续影响你的成本。有些产品初期免费等用户建好数据后再通过配额和功能分层提高订阅转化率。这并不意味着收费不合理但你需要提前知道“这套系统的费用增长曲线”是什么样的。建议在选型时就把“三年后的价格、五年后的迁移成本”纳入估算而不是只对比当前套餐的价格。8.4 控制团队的迁移成本迁移成本不只是数据还有团队习惯。真正让团队离不开一个平台的原因往往不是技术限制而是大家已经习惯了现有的操作方式。所以在选择低代码工具时尽量找交互逻辑接近 Airtable 或团队现有工具的方案并把关键用户纳入试用名单提前验证可接受度。9. 总结与后续学习方向Airtable 被 Bending Spoons 以 22 亿美元收购这件事本身不等于“Airtable 马上要完”。它更是一个明确的信号低代码工具的商业模式正在从“增长优先”转向“盈利优先”。对使用 Airtable 的团队而言短期可以继续正常使用中期则要做好免费版配额和定价策略可能变化的准备。现在最好的行动不是恐慌性迁移而是先做三件事把 Base 清单盘点清楚用 API 做一次全量数据备份然后按“数据控制权、API 深度、成本曲线、迁移成本”四个维度评估 Airtable 是否仍然适合作为长期底座。如果评估结果是没有问题那就继续用下去如果评估结果存在风险就把备份当作起点去验证一两个替代方案的最小可用流程。对于想把数据主动权掌握在自己手里的团队下一步可以重点学习三块内容一是 Airtable 的 REST API 与分页机制打通数据导出通道二是 NocoDB 或 Supabase 这类开源平台的字段映射和导入方法三是数据库设计的基本范式理解关联字段、主键、外键之间的关系。这样无论未来平台策略怎么变你手里始终有清晰的数据边界和替换路径。