Teable

Last reviewed Aug 26, 2026 · 812 words

Teable's argument over the other Airtable-style tools fits in one sentence: it was built on PostgreSQL from the first commit, and it lets you see that. Each base is a Postgres schema, each table is a real table with column names you control, and there is a database-connection feature that hands you a read-only SQL endpoint to point Grafana or a BI tool at. If the point of leaving Airtable is that your data should be reachable by everything else you run, that is the deciding feature. If the point is maximum maturity, it is not: Teable dates from 2023 and gates some features behind an enterprise tier.

Real Postgres is the whole argument

NocoDB and Baserow both store your tables in Postgres too, but they treat it as an implementation detail, with generated column names and a strong hint that you should go through their APIs. Teable treats the database as a product surface. The grid is genuinely fast on tables with hundreds of thousands of rows because the heavy lifting is SQL, not application-side filtering, and the Postgres-for-everything approach to a homelab pays off here: one database server, backed up one way, queried by every tool you own.

The catch is that it is a Postgres-only product. There is no SQLite option for a tiny install and no way to attach an existing MySQL database as a source, which NocoDB does well. If your use case is "put a spreadsheet UI on a database I already have," NocoDB remains the better fit.

Three containers, 1 GB, and one URL you must get right

The catalogue's 1 GB minimum is realistic for the app container; Postgres and Redis add a few hundred MB between them on a small install.

services:
  teable:
    image: ghcr.io/teableio/teable:latest
    ports:
      - "3000:3000"
    environment:
      - PUBLIC_ORIGIN=https://base.example.com
      - PRISMA_DATABASE_URL=postgresql://teable:changeme@postgres:5432/teable
      - BACKEND_CACHE_PROVIDER=redis
      - BACKEND_CACHE_REDIS_URI=redis://redis:6379/0
      - SECRET_KEY=replace-with-a-long-random-string
    volumes:
      - ./teable-data:/app/.assets
    depends_on: [postgres, redis]
    restart: unless-stopped
  postgres:
    image: postgres:16
    environment:
      - POSTGRES_USER=teable
      - POSTGRES_PASSWORD=changeme
      - POSTGRES_DB=teable
    volumes:
      - ./pg:/var/lib/postgresql/data
  redis:
    image: redis:7

PUBLIC_ORIGIN has to be the exact URL users type, scheme included, or attachments and share links point at the wrong host. Set it before you create the first base rather than after. Redis is not optional in the official setup either: the real-time grid and background jobs go through it, and the app refuses to start cleanly without a reachable cache. Give the three containers a private compose network and expose only port 3000 to the proxy. Run the whole thing behind a reverse proxy with TLS from day one; real-time collaboration uses WebSockets, so confirm your proxy passes upgrade headers, which Caddy does by default.

The enterprise line is the thing to read before you commit

Teable is AGPL-3.0, which is fine for a homelab or an internal tool and worth a conversation with a lawyer if you plan to offer it to customers. The more practical constraint is that the open-source build is deliberately incomplete: some collaboration and administration features sit behind an enterprise licence. The core (bases, tables, views, field types, forms, API, SQL access) is there; check the current feature table on the project's site for anything you specifically need, because the split has moved more than once and I would not trust a 6-month-old blog post on it.

Migration from Airtable is CSV-shaped

Teable imports CSV and Excel and infers field types on the way in, which covers plain tables well, and the REST API plus per-table webhooks mean a script can push rows in from anywhere else. Linked records, lookups and rollups do not survive a CSV round trip from anything, so the honest plan is to export every Airtable table, import them all, then rebuild the links by hand while both tools are open. For a base with 10 tables that is an evening; the Airtable alternatives overview covers what else does not transfer, including automations and interfaces, which you will re-create in a separate tool.

What I'd do

Pick Teable if you want your tables to be first-class Postgres tables that Grafana, a Python script and a BI tool can all read without asking the app's permission, and you are comfortable with a project younger than its rivals. Run the 3-container compose above behind Caddy, put the Postgres volume in your nightly backup, and skip the enterprise tier until a specific gated feature blocks you. If you need to wrap a UI around a MySQL database you already run, or you want the longest track record, take NocoDB instead.