Comparison

Busabase vs Lark Base: where should your agents write?

Lark Base is the table a lot of teams already live in: build a base inside Lark, add dashboards and automations, and share it in chat. Busabase is built for a different moment — when more and more of the writing is done by AI agents, and you need to see what each one changed, review it when you want to, and undo exactly the change that was wrong. In Busabase every agent edit is a Change Request with a diff and an author. You bring whichever agent you use. And the whole workspace is open source, so it can run inside your own network, even fully offline.

One note on names: the same product is called Lark Base internationally (run by Lark Technologies, headquartered in Singapore) and 飞书多维表格 (Feishu Bitable) in mainland China. The two editions are priced separately; this page follows Lark Base and lists both prices.

Last verified 13 November 2026 against Lark's product, pricing, help-center and developer pages, Feishu's pricing page, and the current Busabase product.

The short verdict

Choose Busabase

When agents are writing for your team — customer records, research, content, operating docs, Skills — and you want every change visible and reversible, with review when you choose and the data where you decide.

Choose Lark Base

When your team already chats and approves things in Lark, people do most of the data entry, and you need dashboards, automations and row- and column-level permissions today.

Use both

People keep talking and reporting in Lark. Agent output, team Skills and the records that need an audit trail live in Busabase, and results flow back to Lark through the API or webhooks.

The core difference: every change is a Change Request

Think of it as a pull request for your data. In Busabase, every edit — a record, a Doc, a Skill file, a schema change — is a Change Request: a branch with a chain of immutable commits. Merging moves the record forward; nothing is overwritten.

In Lark Base, anyone (or any agent) with edit permission changes a cell and the change is written straight into the table. Afterwards, edit history shows who changed what and when — though Lark notes that "the edit history for records is retained for 180 days" — and the documented way back is to "restore the base to a previous version": the whole base, not one change.

  • A message and a diff on every write. Each change says what it does and shows the field-level before and after.
  • Know which agent did it. The author, and the key or tool the change came through, stay on the commit.
  • History that stays, undo that is precise. Every record, Doc and Skill keeps its full history, and any single change can be rolled back without rewinding everything else.
  • Review when you choose. Writes with write access land immediately. Give an agent a proposal-only key and its changes wait in the Inbox for a person to approve or send back.
A Busabase Change Request under review: its message, a before-and-after diff of a record's body, and Approve or Request changes controls
A Change Request in the Inbox: what changed, who proposed it and through which tool, and the before and after of the field, with Approve or Request changes.

This is what makes it safe to let agents write to the data your team actually uses — not by keeping them out, but by making every change visible and reversible.

What else Busabase gives your agents and your team

All of this comes with the workspace — no add-ons, nothing to assemble.

Bring any agent

Claude Code, Codex, Cursor, DeepSeek and more connect through MCP, the CLI, the OpenAPI REST API, webhooks, the Python SDK and plugins. The agent is yours, not tied to one vendor's platform.

Visual data tables

Every Base opens as a table, gallery, kanban board, calendar or Gantt chart, with saved views and AND/OR filter groups. Teammates check an agent's work in a familiar grid.

A team knowledge base

Docs, files and Bases sit in one tree shared by people and agents. Members join with roles; agents join with their own keys.

Grep across everything

One regex search covers files, Doc bodies, Base records and agent prompts, and returns the line and its context — so an agent finds the exact evidence before it reads further.

Upload your team's Skills

Put the way your team works into Skills once, and every connected agent reads the same version. Editing a Skill is a Change Request like any other.

Apps on four engines

Have an agent build an AirApp on your data and run it in the browser, on your own machine, in a cloud sandbox, or as an always-on website.

Websites on your own domain

The Website engine runs on Cloudflare Workers, can have backend endpoints, and takes a custom domain (Cloud: Plus and above). An agent can preview and publish it.

Permissions by key

API keys come in four levels — read, changeRequest (proposal-only), write and manage — and every node can be private, workspace-wide or shared by grant.

Your data stays in your network

MIT open source. Run it on a laptop, inside your company network — including fully offline, air-gapped setups — or on Busabase Cloud. A space exports to plain files: Markdown, Base definitions and JSON records.
The Busabase Base table view: blog posts written by an agent listed as rows with title, cover image and body columns, plus saved views such as Ready to publish and Drafts
A Busabase Base: articles an agent wrote, with covers and bodies. Saved views such as Ready to publish filter the same records.

Job by job

Each row is something a team actually needs when agents do the work. Lark Base's home ground gets the last row, and its own section below.

The jobBusabaseLark Base
See every change before and after, and who made itBuilt in — a Change Request with a field-level diff, the author and the key it came through; history is keptEdit history with editor, time and change; record history is retained for 180 days
Undo one change and leave the rest aloneYes — any single change can be rolled backRestore the whole base to a previous version; record history lets you copy the old value
Let an agent propose, and apply only after a person looksYes — a proposal-only key sends its changes to the InboxWrites with edit permission apply directly; advanced permissions can limit which rows and columns it edits
Connect Claude Code, Codex, Cursor or your own agentYes — MCP, CLI, OpenAPI, webhooks, plugins; each write is signed by its own keyYes — an official MCP server and the open-source lark-cli with agent skills, plus built-in Base AI features
Give every agent the same team SkillsYes — upload once, every agent reads the same version, edits are Change Requestslark-cli ships skills that teach agents to operate Lark; your own team's skills are not a Base feature
Find an exact string anywhereYes — one regex grep across files, Docs, records and agent promptsKeyword search
See the same data as a table, kanban, calendar or GanttYes — five views, saved views, AND/OR filter groupsYes — grid, kanban, gallery, Gantt, calendar and form views, plus dashboards
Turn data into an app or a websiteYes — AirApps in the browser, on your machine, in a cloud sandbox, or as a website on your domainApp mode inside Lark
Open source, self-hosted, even fully offlineYes — MIT, from a laptop to an air-gapped networkClosed-source cloud service
Export to plain files you can take anywhereYes — Markdown, Base definitions, JSON recordsExcel/CSV export; full configuration needs Lark's proprietary .base format
Work on tables right inside chat, docs and approvalsNot its job — Busabase is not a chat or approvals suiteYes — this is Lark's home ground: messenger, docs, approvals and dashboards in one suite

Coming next

These three are in development and not available yet. They are listed so you can plan; this page will be updated when they ship.

App users In development

People who use an app you publish — a shop's customers, say — sign in with an email code and see only their own records. Enforced by the platform; they are not workspace members and use no seat.

Ontology In development

Define the business objects your team talks about — Company, Contact, Deal — and the links between them on top of your existing Bases, so people and agents share one vocabulary. Ontology changes go through Change Requests too.

Fine-grained permissions In development

Row- and field-level access inside a Base, scoped agent grants with an expiry, and access requests a person approves.

You decide where the data lives

Lark Base is part of Lark's cloud service, and your data lives in Lark's cloud. For most teams that is fine. In mainland China, Feishu also does on-premises deployments for large customers — its site describes one for China Minsheng Bank — but that is an enterprise project you negotiate.

Busabase is MIT open source. A developer can install it on a laptop or inside the company network this afternoon, and it keeps working with no internet connection. Your agents read and write data on your machines, so customer lists, contracts and internal policies never have to leave your network. Move to Busabase Cloud later, or back again, by exporting the space to plain files.

That matters most for two kinds of teams: those with data-residency or industry compliance rules, and those that want agents working on sensitive business data without handing that data to any one platform.

Using them together

Teams already on Lark often split the work like this:

  1. Chat, meetings, approvals and the dashboards leadership looks at stay in Lark.
  2. A sales agent researches target accounts and writes them into a customer Base in Busabase. Every edit is a Change Request the sales lead can check in the Inbox.
  3. Talk tracks, pricing rules and delivery standards live as Skills in Busabase, so every agent works from the same version.
  4. Finished results go back to a Lark group through Busabase webhooks or the API — or an agent publishes them as an AirApp website.

Neither replaces the other. Lark keeps people working smoothly together; Busabase makes what agents write trustworthy.

Pricing at a glance

Busabase

Free: 1 space, 3 seats, 5,000 records, 20 nodes, 1 GB, every node type including Skills, workflows and AirApps.
Plus: $10 per seat per month, billed yearly. Pro: $20, billed yearly.
Flat per seat, no metered overage. Self-hosting is free under MIT, with no seat limit.

Lark (international)

Suite: Starter $0 (up to 20 users, 2,000 rows per table), Basic $6, Pro $12 (20,000 rows per table, Base advanced permissions), per user per month, billed annually.
Lark Base on its own: Pro $8 per user per month, billed annually.

Feishu (mainland China)

Free: ¥0, up to 100 users, includes Base.
Business Standard: ¥50 per user per month. Business Pro: ¥80, adds advanced Base capabilities. Business Flagship: ¥120. Enterprise is custom.
All editions are billed annually.

Public prices as of 13 November 2026 (Lark in USD excluding tax, Feishu in CNY). Check Busabase pricing, Lark plans, Lark Base plans and Feishu pricing for current figures.

Where Lark Base is the better choice

  • Your team already works in Lark. Chat, docs, meetings and approvals are there, and Base sits inside them with almost no training.
  • People do most of the data entry and reporting. Lark Base's dashboards ("over 20 chart types that update in real time"), automations, forms and mobile entry are mature.
  • You need row- and column-level permissions today. Lark's advanced permissions let specific members view or edit only specific records and fields.

Busabase's plain limits: it is not a chat, meetings or approvals suite; row- and field-level permissions inside a Base are in development; and sign-in for end users of the apps you publish is in development, not available yet.

FAQ

Are Lark Base and Feishu Bitable the same product?
They are two editions of the same product: Lark Base internationally and 飞书多维表格 (Feishu Bitable) in mainland China. Accounts and pricing are separate.
Lark Base has edit history. How is a Change Request different?
Edit history tells you what changed after it happened. A Change Request is the change itself: it carries a message and a field-level diff, can wait for review before it applies, and can be undone on its own. Lark keeps record history for 180 days and undoes by restoring the whole base to a version; Busabase keeps history and rolls back any single change.
Lark has its own AI features. Why add Busabase?
Lark's AI lives inside Lark and works well there. Busabase is built for the agents you choose — Claude Code, Codex and others. Each connects with its own key, every edit it makes carries its author and can be reviewed and undone, and all of them read the same team Skills.
Does every agent write need approval?
No. Writes with write access apply immediately and keep their history. Review is optional: give an agent a proposal-only key and only then do its changes wait in the Inbox.
Can I move data from Lark Base into Busabase?
Yes. Have an agent read the data through Lark's API (or from an Excel/CSV export) and write it into a Busabase Base. Every write is a Change Request, so you can check the migration record by record.
Can Busabase run inside our network, fully offline?
Yes. It is MIT open source and runs on a laptop, your own servers, or an air-gapped network. See the self-hosting guide.

Next step

Connect the agent you already use and have it put one real piece of work into a Base — an account list, a content calendar, a project tracker. Then open the Inbox and see exactly what it changed.

Related: All comparisons · Busabase vs Notion · Busabase vs Supabase · How Change Requests work · Search and grep · Publish an AirApp as a website

Sources: Lark Base product page, Lark Base plans, Lark plans, Lark Help Center: View edit history in Base, Lark Help Center: Use advanced permissions in Base, Lark Help Center: Import or export a base, Lark/Feishu Open Platform: MCP, lark-cli, Feishu pricing, Feishu: Minsheng Bank deployment