Teable

Teable is an open-source, no-code database platform built directly on PostgreSQL, giving non-technical users a familiar spreadsheet interface while providing the scale and reliability that production data workloads require. It handles millions of rows without performance degradation, making it a genuine alternative to Airtable for teams whose data needs have grown past what cloud-only no-code tools can handle.

The platform ships with five built-in view types — Grid, Form, Kanban, Gallery, and Calendar — plus real-time multi-user collaboration powered by ShareDB-based operational transformation. Every change is tracked with full record history and undo/redo support, so teams can collaborate without fear of data loss.

Teable 2.0 introduced a native AI agent layer that lets users create databases, build apps, automate workflows, and analyze data through natural language conversations. The AI integrates with multiple LLM providers including OpenAI, Anthropic, AWS Bedrock, and OpenRouter, with support for bring-your-own-key configuration at the space level.

Deployment is straightforward via Docker Compose with PostgreSQL and Redis, or through one-click deployers on Railway, Zeabur, Sealos, and Elestio. The monorepo ships a v2 architectural rewrite underway that uses port/adapter patterns, making the collaboration engine, storage backend, and formula SQL transpiler independently replaceable components.

What You Get

• Real-Time Collaborative Editing - Multiple users edit records simultaneously with operational transformation (ShareDB-based), so concurrent changes never conflict and every keystroke appears instantly for all collaborators.
• Five Flexible View Types - Switch between Grid, Form, Kanban, Gallery, and Calendar views on the same data without duplicating records, letting each team member work in the format that suits their workflow.
• Native AI Database Agent - Describe what you want in plain language and the AI creates tables, generates apps on top of live data, writes automations, and produces analysis — all connected to your actual records, not a static mock.
• PostgreSQL Backend with Million-Row Scale - Data lives in a real Postgres database you control, with demonstrated performance on 1M+ row tables, SQL query access, and formula fields using an ANTLR-based grammar transpiled to SQL.
• Plugin System with TypeScript SDK - Extend the platform with custom plugins using the provided SDK; the architecture supports floating panel plugins, table plugins, and context menu plugins deployable alongside the core app.
• Full Self-Hosting via Docker - Deploy with a single docker-compose up using the standalone example that wires together the app container, PostgreSQL, and Redis; one-click deployers exist for Railway, Zeabur, Sealos, and Elestio.
• Base Import/Export in .tea Format - Export any base to a portable .tea archive (a ZIP with full schema and data) and re-import it to any Teable instance, enabling backups and migrations without vendor lock-in.
• Complete Audit Trail with Undo/Redo - Every record change is versioned with full history accessible per-record; undo and redo work across sessions so mistakes are always recoverable.
• Flexible Attachment Storage - File attachments integrate with S3-compatible storage including AWS S3, MinIO, and AliCloud OSS, configurable via environment variables without code changes.
• Multi-LLM AI Configuration - Administrators configure AI providers at the instance level (OpenAI, Anthropic, AWS Bedrock, OpenRouter, or AI Gateway); individual spaces can add bring-your-own-key overrides for cost control.

Common Use Cases

• Building a team CRM without engineers - A sales team configures tables for contacts, deals, and activities, uses Kanban view for pipeline stages, and adds AI-powered fields that score leads and draft follow-up messages from CRM data.
• Managing a content production pipeline - A media team tracks articles, assets, review status, and publish dates across Grid and Calendar views, with form submissions from external contributors feeding directly into the editorial table.
• Consolidating spreadsheet chaos into a shared database - An operations team imports dozens of Excel files into Teable using the built-in Excel importer, letting the AI map columns and resolve duplicates, then shares a single source of truth with the whole organization.
• Running internal tools at startup scale - A small engineering team builds a vendor management system, a bug tracker, and an onboarding checklist — all in Teable — without standing up separate databases or writing backend code.
• Replacing Airtable for regulated industries - A healthcare or fintech team moves off cloud Airtable onto a self-hosted Teable instance to satisfy data residency requirements while keeping the familiar spreadsheet-style interface their operations team depends on.
• Batch AI content generation - A marketing team stores product catalog data in Teable and uses AI field configuration to batch-generate product descriptions, image prompts, and ad copy for every row simultaneously.

Under The Hood

Architecture

Teable is organized as a pnpm monorepo with a clear separation between apps (the NestJS backend and Next.js frontend), shared packages (core types, SDK, Prisma schema, formula engine), and plugins. The NestJS backend uses module-based dependency injection with 49 domain feature modules — each owning its own controller, service, and module registration — and a layered data flow from HTTP controller through service to Prisma ORM. A concurrent v2 architectural rewrite introduces port/adapter patterns with 39 adapter packages, allowing the collaboration engine (ShareDB or BroadcastChannel), storage backend (pg, pglite, or postgresjs), and formula SQL transpiler to be replaced independently without touching domain logic. WebSocket-based real-time collaboration runs through a dedicated ShareDB gateway, separated from the REST API path.

Tech Stack

The backend runs TypeScript on Node.js with NestJS, using BullMQ for async job queues (imports, exports, AI tasks), Redis for caching and queue backing, and Prisma ORM targeting PostgreSQL as the primary database with SQLite available for development. The frontend is Next.js 14 with server-side rendering and OpenAPI-generated TypeScript types shared across the stack. Formula fields use an ANTLR grammar that transpiles expressions to PostgreSQL SQL, supporting the full Airtable-compatible formula set. AI features use the Vercel AI SDK, supporting OpenAI, Anthropic, AWS Bedrock, and OpenRouter providers. File attachments connect to any S3-compatible object store. Observability is provided through OpenTelemetry tracing and Sentry error tracking.

Code Quality

The codebase has extensive test coverage with over 900 unit spec files and more than 150 end-to-end specs exercising real database interactions. TypeScript strict mode is enforced across the monorepo with Zod schemas providing runtime validation on all API inputs, plugged into NestJS as a custom validation pipe. ESLint and Prettier are configured via shared workspace packages and enforced in CI. The v2 packages use tsdown for builds and enforce source visibility so consumers can reference TypeScript sources directly. Error handling is explicit with structured exception types and deadlock retry logic built into database write paths. Husky pre-commit hooks and commitlint enforce code quality gates before any code reaches the repository.

What Makes It Unique

The most distinctive technical decision is grounding the no-code experience on a real PostgreSQL schema where each base is a set of actual Postgres tables, not a JSON blob in a document store. This means SQL queries work on the data natively, row-level permissions translate to real database constraints, and million-row performance is a consequence of the database engine rather than special optimization. The concurrent v2 rewrite with swappable adapters for realtime, storage, and formula evaluation is unusual for a project of this size and signals architectural ambition beyond typical no-code tools. The AI field system integrates LLM providers at the field level — individual columns can have AI configuration that generates values on demand, batch-processes existing records, or responds to automation triggers — treating AI as a first-class data type rather than a bolt-on chatbot.

Self-Hosting

Teable uses a dual-license model. The core applications — the NestJS backend and Next.js frontend — are licensed under AGPL-3.0, while all packages in the packages/ directory (SDK, core types, formula engine, Prisma schema) are MIT-licensed. For self-hosters, the AGPL-3.0 license means you can run Teable freely in production and modify it, but any modifications to the covered code that you distribute or expose as a network service must also be released under AGPL-3.0. This is standard for open-core SaaS alternatives and does not restrict internal use or private deployments.

Running Teable yourself requires PostgreSQL, Redis, and an S3-compatible object store for attachments — three infrastructure components that each need their own availability, backup, and scaling strategy. The standalone Docker Compose example provisions all three, but a production deployment needs external managed versions of each to avoid single-node failure. Database migrations run as a separate step before the app starts, and the schema evolves with each release, so upgrade procedures must include migration execution. There is no built-in clustering for the app layer; horizontal scaling requires external load balancing and session-sticky configuration for the WebSocket collaboration gateway.

Teable Enterprise Edition adds features not in the community release: AI chat over your database, automation workflows, an authority matrix for cell-level permissions, custom branding, department management, audit logging, and advanced user management. The cloud version at teable.ai includes managed hosting, SLA-backed uptime, automatic backups, and direct support. Self-hosted community users have access to the GitHub issue tracker and community forum but no formal SLA. For teams evaluating the trade-offs, the managed cloud removes the operational burden at the cost of data residency control — the opposite of what most teams choose self-hosting for — making the decision primarily about whether your compliance or cost requirements justify owning the infrastructure.