# Teable Review: A PostgreSQL-Backed Airtable Alternative That Runs AI Agents > Teable puts a spreadsheet interface on top of PostgreSQL, then adds AI chat, an app builder and an automation engine. Here is how the pieces fit, how to self-host it, and where it stops being the right tool. **teableio/teable** — ✨ AI Spreadsheet for Business - Repository: https://github.com/teableio/teable - Website: https://teable.ai - Stars: 21,850 · Forks: 1,351 - Language: TypeScript - License: NOASSERTION - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/teableio-teable ## What Teable Is Trying To Fix Most teams end up with the same split. Product and ops people want a grid they can edit without writing SQL. Engineers want the data in PostgreSQL, where they can query it, back it up and connect it to everything else. Airtable-style tools solve the first half and hide the second. Teable's pitch is that both halves are the same system: a spreadsheet interface on top of a real PostgreSQL database, with an API, permissions and views on top. The repository description calls it an "AI Spreadsheet for Business", and the README frames the product as four platforms in one: an agent sandbox, an app deployment platform, an AI workflow engine, and a database collaboration platform. That framing tells you who it is for. It is aimed at teams that want internal tools built by the people who understand the process, not by a platform team with a ticket queue. If you only need a hosted grid for a marketing content calendar, the AI and app-builder layers are weight you will pay for in deployment complexity. ## The Four Runtime Pieces And How They Fit The README is explicit that self-hosting deploys four things, and the distinction matters when you size a machine. First, an agent sandbox: every AI session runs in its own isolated container, started on demand and destroyed when the session ends. Second, an app deployment platform: each app a team publishes runs as its own lightweight, long-lived container. Third, an AI workflow engine whose automations fire on record changes, schedules and webhooks, with AI steps in the chain. Fourth, the database collaboration layer itself, built on PostgreSQL, with tables, views, permissions and API. The split between short-lived sandbox containers and long-lived app containers is the part worth understanding before you deploy. Sessions come and go, so their resource use is bursty. Published apps stay up, so their footprint accumulates with every app your team ships. Neither is described in the README with concrete CPU or memory numbers, and the deployment guide is where that detail would live. Plan capacity around the number of published apps you expect, not around the number of people using the grid. The codebase is a pnpm monorepo in TypeScript, with apps, packages, packages/v2 and plugins as workspaces. The package.json shows a version of 1.10.0 and a license field of AGPL-3.0, while the repository itself carries both a LICENSE file and an AGPL_LICENSE file. That discrepancy is worth reading yourself rather than trusting a summary. ## Running Teable Locally From Source The README's development section is short and assumes a working Node toolchain. It starts by enabling Corepack so the pinned package manager is available, then installs dependencies across the workspace. ```bash corepack enable pnpm install ``` After that, the README points at a Makefile target to bring up PostgreSQL. The Makefile defines a database URL of postgresql://teable:teable@127.0.0.1:5432/teable with statement_cache_size=0, and the comment above it explains why: prepared statement caching is disabled to avoid a cached plan error after field schema changes. ```bash make switch-db-mode ``` Environment variables are optional at this stage. The README copies a development env file into a local override, which is where you would put anything you do not want committed. ```bash cd apps/nextjs-app cp .env.development .env.development.local ``` The README's fourth step, running the dev server, is cut off in the text available, so treat the three commands above as the documented setup and read the repository for the start command. If you would rather not run it from source, the README points at a hosted version at teable.ai and at a Docker guide for standalone self-hosting. ## Standalone Versus Full-Featured Self-Hosting This is the decision that trips people up, and the README's comparison table settles it. Three deployment shapes exist. Teable Cloud at teable.ai gives you tables, collaboration, API, automation, AI features and App Builder. The full-featured self-host gives you the same set on your own machines. The standalone self-host gives you tables, collaboration, API and automation, but no AI features and no App Builder. So the standalone Docker path is not a smaller version of the same product. It is a different product with the AI runtime plane removed. If you deploy standalone and then discover you wanted AI chat, the README states that the runtime plane installs next to an existing standalone deployment and your data stays in place, with a migration guide in the teable-deployment repository. That is a real escape hatch, but it means a second deployment exercise rather than a config flag. The README also suggests handing the teable-deployment repository to a coding agent along with a domain, a DNS token and access to the target machine, so the agent can run the deployment end to end. That is an unusual recommendation to see in a README, and it tells you the maintainers expect the full deployment to be fiddly enough that automation is the preferred route. ## Where Teable Is The Wrong Choice The clearest limitation is structural: the AI and app-building features are not available in the standalone self-host. A team that wants a self-hosted Airtable replacement on a single small VM is choosing between the standalone image without AI, or the full stack with container orchestration for agent sandboxes and per-app containers. The README does not describe a middle path. The second limitation is operational. Running per-session sandbox containers and per-app long-lived containers is a container platform workload, not a single-process web app. If your team has no one who wants to own that, the hosted version removes the problem by removing the deployment. Third, the README makes broad claims about scale, including "millions of rows without breaking a sweat", with no benchmark, hardware description or dataset behind it. Treat that as a marketing line, not a capacity plan. The Makefile's prepared-statement workaround is a more honest signal of how the system behaves under schema change: altering fields can invalidate cached plans, which is a normal consequence of mapping a spreadsheet's mutable schema onto PostgreSQL. Finally, the repository carries both LICENSE and AGPL_LICENSE files while the package metadata says AGPL-3.0. If your organisation has rules about AGPL code in internal tooling, resolve that ambiguity before you build on it. ## How It Compares To NocoDB The most common comparison is with NocoDB, and the difference is in what sits underneath and what sits on top. Both present a spreadsheet interface over a relational database, and both are self-hostable. Teable's README states plainly that the data lives in PostgreSQL, and the repository's topics list postgres and postgresql alongside airtable-alternative. That means the tables you build are PostgreSQL tables you can reach with any PostgreSQL client, which matters if you already have a Postgres instance, a backup routine and a BI tool pointed at it. The bigger divergence is the AI layer. Teable ships an agent sandbox, an app builder that deploys generated apps to their own URLs, and automations with AI steps. That is a bet that the spreadsheet is the place where non-engineers will describe what they want and get a working internal tool. If you want a grid and an API and nothing else, that layer is cost without benefit, and a lighter self-hosted grid will be easier to keep running. If you want the app-building path, the comparison stops being about the grid at all. ## Licence, Maintenance And Upgrade Cost The last push to the default branch, develop, was on 2026-09-20, and the most recent releases are dated 2026-09-19 and 2026-09-18. The repository is not archived. The release naming convention, release.2026-09-19T11-56-47Z.3177, embeds a timestamp and a build number, which suggests frequent automated releases rather than occasional hand-cut versions. Frequent releases are good for fixes and bad for anyone who wants a quiet upgrade path, because you have to decide how often to move. On licensing, the package.json declares AGPL-3.0, and the repository contains both AGPL_LICENSE and LICENSE files at the top level. AGPL obligations attach to network use, which is exactly how a self-hosted internal tool is used. I am not giving legal advice; the point is that two licence files and a metadata field are three sources, and they should agree before you rely on any of them. Upgrade cost is dominated by the deployment shape. A standalone deployment is a container upgrade. A full-featured deployment has a runtime plane with sandbox and app containers, and the README's own migration guide for moving from basic to full-featured exists because that transition is not trivial. Budget for the migration path, not just the install. ## Conclusion Adopt Teable if you want a spreadsheet UI over PostgreSQL that you control, and if the AI chat, app builder and automation engine are features you will actually use. Skip it if you only need a plain relational database with a REST layer, or if you cannot run the container stack that the full-featured deployment requires. Before committing, verify the licence terms of the AGPL_LICENSE and LICENSE files in the repository, confirm which deployment path matches your infrastructure by reading the deployment guide, and check whether the standalone image you plan to run includes the AI features or leaves them out. ## FAQ ### What is Teable used for? Teable is used as a spreadsheet-style database platform for building internal tools and managing business data, with tables, views, permissions and an API on top of PostgreSQL. The README also describes AI chat, an app builder that deploys generated apps, and automations triggered by record changes, schedules and webhooks. ### How does Teable compare to NocoDB? Both present a spreadsheet interface over a relational database and can be self-hosted. Teable's README states that the data sits in PostgreSQL, and the repository topics list postgres and postgresql, so the tables are reachable with standard PostgreSQL tooling; the larger difference is that Teable bundles an agent sandbox, an app builder and AI automations, which a plain grid tool does not. ### Can I self-host Teable with Docker? Yes. The README's deployment table lists a standalone self-host with a Docker guide, and a separate full-featured self-host path through the teableio/teable-deployment repository. The standalone option includes tables, collaboration, API and automation, but not the AI features or the App Builder. ### Does the standalone self-hosted Teable include the AI features? No. The README's comparison table marks AI features and App Builder as unavailable in the standalone self-host. The README states that the runtime plane can be installed next to an existing standalone deployment with the data staying in place, following a migration guide in the teable-deployment repository. ### What database does Teable run on? PostgreSQL. The README describes the database collaboration platform as running on PostgreSQL, the repository topics include postgres and postgresql, and the Makefile defines a local database URL of postgresql://teable:teable@127.0.0.1:5432/teable with statement_cache_size=0. ### What licence does Teable use? The package.json declares AGPL-3.0, and the repository contains both an AGPL_LICENSE file and a LICENSE file at the top level. Because those sources do not obviously agree, read the licence files in the repository directly rather than relying on the metadata field. ## Sources - [Issues](https://github.com/teableio/teable/issues) - [Project website](https://teable.ai) - [README](https://github.com/teableio/teable/blob/develop/README.md) - [Releases](https://github.com/teableio/teable/releases) - [teableio/teable on GitHub](https://github.com/teableio/teable) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/teableio-teable