Five views sit on one PostgreSQL-backed data layer
Teable's 8,267-file repository backs five familiar ways to work with the same records: Grid, Form, Kanban, Gallery, and Calendar. Under that spreadsheet-like surface sits PostgreSQL, with formulas, linked records, permissions, comments, history, imports, exports, charts, plugins, search, and an API. That combination solves a common problem: people can edit data without living in a database console, while developers still have a relational store and HTTP interface behind the screen.
The full product reaches beyond collaborative tables. Teable describes four platforms in one self-hosted system: the database application, an AI workflow engine, isolated agent sandboxes, and a deployment platform for generated apps. AI chat can work against live records, automations can respond to changes or schedules, and App Builder can publish an app connected to the same data. That is useful when these jobs belong together. It is expensive overhead when all you needed was a nicer table editor.
Standalone drops AI, while the full host needs four DNS records
Full self-hosting requires 4 DNS records, while standalone keeps the deployment smaller by excluding AI chat and App Builder. The full host restores those headline features. Its separate deployment repository maps the records to the main app, infrastructure service, deployed apps, and sandbox previews. Local Docker can use *.localhost; a server needs control of a real domain or internal DNS.
The full installation has two operating planes. The application plane carries PostgreSQL and Redis. The runtime plane adds a sandbox engine, an infrastructure console and API, a git registry, object storage, and a preview gateway. Docker all-in-one puts that set on one machine, while the Helm route targets an existing Kubernetes cluster and recommends an isolated sandbox node pool. Teable supplies doctor scripts for both paths, which helps, but somebody still owns upgrades, backups, secrets, model keys, and capacity.
What happened when we ran it
Our sandbox installed Teable in 92 seconds. Pnpm pulled 4,063 packages, and the resulting dependency tree occupied 2,801 MB on disk. The checkout itself held 8,267 files, about 1,365,757 lines of source, and measured 63.9 MB. Those figures came from commit 5ef2238 in an unprivileged Debian container with 3 CPUs and 8 GB of RAM.
The run stopped after installation because the repository exposed no build script or target and no test script or target. Both steps were skipped; there was no compiler or test failure to diagnose. Our scan also found 11 CI workflow files, a workspace monorepo, no Dockerfile, and no tests directory. Teable does have an official container image and a separate deployment repository, so the missing Dockerfile describes this checkout rather than the product's shipping options.
This result leaves an important gap. A successful 92-second dependency install proves that pnpm could resolve this commit in our sandbox. It says nothing about whether the backend starts, migrations complete, browser workflows behave, or the full runtime plane is healthy. How we test reports unavailable targets as unavailable; it does not turn a skipped check into a pass.
Open issue 3639 reports a junction table lost during field deletion
Teable had 86 open issues on September 27, including issue #3639 about a lookup over a many-to-many link whose deletion also removed the shared PostgreSQL junction table. Later record inserts returned HTTP 500, and the reporter restored the relation from a pg_dump. The report names the standalone image released on August 9, 2026, so it should not be stretched into a claim about every Teable version. It is still a good reason to rehearse restores and stage field changes before editors use them on production data.
A separate open report, #3624, alleges that local-storage attachment tokens were not bound to a file path and that a default encryption key allowed forgery when operators did not override it. We did not reproduce that report. The September 25 release added wider audit logging, tighter deactivated-account handling, and password-share changes, but its notes do not say that #3624 was resolved. Security-sensitive teams should verify the current attachment path and set every storage secret explicitly.
The applications use AGPL, with MIT packages and extra brand terms
Teable licenses its Next.js and NestJS applications under AGPL-3.0, while packages under packages/ use MIT licenses. The repository's top-level license also adds brand-protection terms that prohibit modifying, replacing, or removing Teable brand assets. Open issue #2540 questions how those terms interact with AGPL section 7. That discussion is unresolved on GitHub, and this review cannot settle it. A company planning a branded fork should get a license review before it builds around that assumption.
The commercial line is separate from the source license. Teable says its official image contains the complete product, while paid plans unlock AI features and advanced enterprise capabilities in place through a license key. This avoids an image migration, but it also means self-hosted does not equal every feature at no charge. Compare the exact plan with the free standalone feature table before promising AI chat or App Builder to users.
A September 27 push and 140 open items show active development
GitHub recorded 21,829 stars and a last push on September 27, 2026. Search results split the 140 open items into 86 issues and 54 pull requests. The latest release arrived on September 25 with OAuth notification permissions, more audit events, changes to protected shares, and a renamed scrape parameter. Those are signs of current work, while the open queue shows how much product surface the maintainers and contributors are carrying.
The 2,801 MB dependency tree makes Teable easiest to justify when one system can replace scattered tables, small internal apps, and record-driven automations. Start with standalone if the five views and API solve the job. Move to the full platform only when AI chat or App Builder has a named owner, a budget, and a deployment plan. With 4,063 installed packages before any service started in our run, that second choice deserves architecture review rather than an optimistic afternoon rollout.