No-code databases in 2026: revisit NocoDB, Baserow and Teable before you move another team spreadsheet off Airtable

Almost every company has one spreadsheet that quietly became a database. It started as a list of suppliers or a dispatch tracker in Google Sheets. Then somebody added a dropdown, somebody else added a second tab that looks up the first, and one day a team lead moved it to Airtable because it needed linked records, forms and a kanban board. Three years later that Airtable base runs a real business process, holds customer and staff details, and is understood by one person who is about to go on leave.

At some point the company asks whether it can keep the same way of working on its own servers. This post is about that question. A no-code database looks like a friendly spreadsheet, but underneath it is a multi-user application with an API, sharing links, automations and personal data. The wrong choice shows up as a broken formula, a public link that shows too much, or a licence clause nobody read.

We revisit three self-hosted tools that people actually run in 2026 as Airtable alternatives: NocoDB (a Node.js application that puts a spreadsheet interface on a database, now under the source-available Sustainable Use License), Baserow (a Django and Nuxt application whose core is MIT licensed, with paid Premium and Enterprise code in the same repository) and Teable (a NestJS and Next.js application built on PostgreSQL, under AGPL-3.0 for its community edition, with a paid licence for extra features). We checked whether one of them should be swapped out. Grist is a strong Apache-2.0 option, and we say more about it in the history section, but it is a different kind of tool, closer to a spreadsheet with Python formulas than to an Airtable clone. So we kept the three that most teams compare when they leave Airtable, and we label NocoDB’s licence clearly, because it is no longer OSI open source.

There is real news this autumn, and much of it is about security. NocoDB moved to date-based versions in April 2026, shipped 2026.10.0 on 23 October and 2026.10.1 on 29 October, and published a long series of security advisories, including two rated critical, with many published on 27 October and 2 November. Baserow 2.4.0 arrived on 30 September with a button field, field permissions for users and teams, and stricter checks on SAML signatures and OIDC email verification, and 2.4.1 followed on 13 October and declared its Application Builder ready for production. On 15 October Baserow published eight advisories for issues already fixed in earlier 2.2 and 2.3 releases. Teable, which releases several times a week, published a large batch of advisories on 13 October, the most serious being a REST API path that did not check resource-level permissions, fixed in its 12 October release.

This post sits between our posts on internal tool builders, workflow automation and PostgreSQL backups. A no-code database is where business users keep the data, and the other three depend on it.

A scenario to keep us honest

We will use one invented company through the post. Malaprabha Castings and Components is an invented example, not a real business: a Belagavi company that casts and machines grey iron and ductile iron parts for pump makers, tractor component suppliers and two automotive tier-one companies in Pune and Kolhapur. It has about 220 people across a foundry, a machine shop and an office. IT is a team of three, led by Shrinivas, who looks after the ERP on a MySQL database, Google Workspace, the network and the CCTV recorders.

What they use today:

  • An Airtable workspace started by the quality team four years ago. It has three bases. “NCR and CAPA” tracks non-conformance reports and corrective actions, with links to parts, customers and suppliers, photos of defects and a few formulas that calculate days open. “Supplier ratings” holds about 140 suppliers of sand, alloys, resin and machining tools with monthly scores. “Tooling and patterns” tracks every pattern and core box, where it is stored and when it was last repaired. About 25 people edit, and about 40 more only view.
  • A Google Sheet called “Dispatch tracker” with one tab per customer, updated by the dispatch team every evening and read by sales.
  • A second Google Sheet with contract labour details, including names, phone numbers and bank account digits, kept by the HR executive.
  • Two Airtable automations that send email when an NCR crosses 15 days, and a form that shop supervisors fill on their phones.

What triggered the review: the Airtable renewal came with a higher cost for the seats the quality team now needs, and the plant head asked why viewers in the machine shop also need accounts. In the same quarter, an automotive customer’s supplier audit asked where quality records and supplier contact details are stored, who can see them and how they are backed up. And a formula in the NCR base broke silently after somebody renamed a field, so the “days open” column showed blanks for a week before anyone noticed.

Shrinivas’s questions: which tool, whether it is really open source, how users sign in and what they can see, how much server it needs, what moves from Airtable and Google Sheets and what does not, how backups and upgrades work, and whether three IT people can keep it patched given how many security fixes these projects shipped this year.

The short version

  • All three are alive and moving fast, but they are not the same kind of project. NocoDB is the oldest and best known, and is strongest when you want a spreadsheet view over an existing PostgreSQL or MySQL database. Baserow is the most complete self-contained Airtable replacement, with its own database, Application Builder and automation builder. Teable is the youngest, built on PostgreSQL from the start, with a fast release pace and an emphasis on scale and real-time collaboration.
  • NocoDB is no longer open source in the OSI sense. Since 0.301.0 in January 2026 it uses the Sustainable Use License, which allows use for your own internal business purposes and for non-commercial or personal use. For an internal tracker that is usually fine. For anything you resell or host for customers, read the licence and ask the vendor. Single sign-on and some data sources sit in paid plans.
  • Baserow keeps its core, the Baserow Open Source Edition, under MIT. Kanban, calendar and timeline views, row comments, some exports and AI fields are Premium code. SSO, audit logs, role-based permissions, field permissions and some other features need an Advanced or Enterprise licence. Every Baserow table is a real PostgreSQL table, and it has the most detailed Airtable importer of the three, with an import report.
  • Teable is AGPL-3.0 for the backend and frontend apps, MIT for shared packages, with extra brand terms. Its source contains OIDC sign-in and an Airtable importer, but some features such as the field and record permission matrix, BYODB and the full AI stack need a paid self-hosted plan. It published 48 advisories this year, and its release pace means you must decide how often you will upgrade.
  • For Malaprabha we recommend a structured pilot of Baserow 2.4.1 on Docker Compose with its own PostgreSQL, starting with the NCR and CAPA base imported on a throwaway instance, Google sign-in deferred until the licence question is answered, and Teable as the second candidate if the team wants SQL access to the same data. Details later.
  • Do not migrate the base. Migrate the process. The value is in clean records, their links and the few calculations people trust. Clean up half-used views, unexplained formulas and old share links before any import.

Where things stand on 2 November 2026

NocoDB

NocoDB’s GitHub repository has about 65,000 stars and is the most watched project of the three. Version numbers changed this year. The 0.301 line ran from 0.301.0 on 13 January 2026 to 0.301.5 on 18 March, and from 2026.04.0 on 13 April the project uses date-based versions. Since then it has shipped roughly two releases a month: 2026.08.0, 2026.08.1 and 2026.08.2 in August, 2026.09.0 and 2026.09.1 in September, and 2026.10.0 on 23 October and 2026.10.1 on 29 October (dates from GitHub, in UTC).

The 2026.10.1 notes are a mix of features and hardening. Timestamps now carry milliseconds on PostgreSQL and SQLite in the API, webhooks and CSV export. The built-in MCP server at /mcp lists every tool, with a /mcp-discovery endpoint for clients that cap the number of tools, and now has rate limits. Changing a password deletes the user’s API tokens and disconnects OAuth apps. For self-hosters, setting only NC_ATTACHMENT_ACCESS_CONTROL_ENABLED=true now turns on secure attachments, which means the old /download and /dl paths stop serving files and signed URLs are used. 2026.10.0 renamed “Interfaces” to “classic apps” and added workflow run playback, which is available in the Community edition too. 2026.04.0 brought a Map view, UUID and Auto Number fields and a new link architecture, LTAR V2, that uses junction tables for all relation types and deprecates the legacy Links field.

The security record is the headline. NocoDB’s GitHub page lists 121 published advisories, 116 of them published in 2026. By the GitHub severity labels, two of the 2026 ones are critical, 42 high, 55 medium and 17 low. We cover what they teach later.

Baserow

Baserow is developed by Baserow B.V. in the Netherlands. Development moved from GitLab, where releases stop at 1.35.3 in October 2025, to GitHub, where the current releases are. 2.0.0 came out on 18 November 2025 with an automation builder, an AI assistant called Kuma, TOTP two-factor authentication and an AI agent action in workflows. 2.1.0 followed in February 2026, 2.2.0 in April, 2.3.0 in July with fixes up to 2.3.4 in September, 2.4.0 on 30 September and 2.4.1 on 13 October.

2.4.0 is worth reading in full before an upgrade. It added a button field, field permissions for specific users and teams, AI provider management, a “start workflow by email” trigger and Airtable import from publicly shared views. Its security changes enforce signature validation on SAML responses and assertions and check that an OIDC or OAuth2 email is verified before binding to an existing account. It also has breaking changes: AI provider environment variables are imported once and then ignored, the SMTP password and Slack token are no longer returned by the API, and BASEROW_DATA_SYNC_ALLOW_PRIVATE_ADDRESS=false now blocks PostgreSQL data syncs to private hosts. 2.4.1 moved the Application Builder out of beta, fixed the Helm chart, and added SMTP over port 465.

Baserow lists eight GitHub advisories, all published on 15 October 2026 for issues fixed between 2.2.0 and 2.3.1. One is rated high: unauthenticated data exposure in the Application Builder, fixed in 2.3.1.

Teable

Teable’s repository was created in November 2022 and has about 22,000 stars. It does not use semantic version tags. Releases are named by build time, such as release.2026-11-01T07-52-11Z.3675, published on 1 November 2026, and there are often several a week. Docker images come in a latest stable channel and a beta channel. The application’s own package.json at that tag says version 1.10.0.

The README describes Teable as a no-code database with “real PostgreSQL underneath”. It now offers two self-hosting paths: a standalone Docker Compose setup and a fuller deployment that adds AI chat, an App Builder and code sandboxes. The repository is the Community edition. The official image ghcr.io/teableio/teable ships the full product with paid features unlocked by a licence key, and ghcr.io/teableio/teable-community contains only the community features.

Teable lists 48 GitHub advisories, all from 2026: 26 high, 20 medium and 2 low. The large batch published on 13 October was fixed in release.2026-10-12T12-45-53Z.3331. Later ones include an authorization gap in the real-time presence channel (fixed in build 3650) and an SQL injection through the currency symbol option of a field (fixed in build 3593).

The first questions to ask

Before comparing features, Shrinivas should answer these for Malaprabha. The answers decide the tool more than any feature list.

  • Is this a new database, or a view over an existing one? If the quality team wants a fresh place for NCRs, any of the three works. If sales wants to browse ERP tables in MySQL without writing SQL, only NocoDB is designed for that. Teable’s BYODB keeps a space’s data in a PostgreSQL you choose, but it does not attach existing business tables.
  • Will anyone outside the company use it? Supplier portals, customer forms and public views change the risk. They also matter for NocoDB’s licence if the use stops being internal.
  • Who must sign in with company accounts? If single sign-on is a must on day one, all three put it in a paid tier for the full feature, though Teable’s community source includes OIDC. Price that early.
  • Who needs to see which rows and fields? “Quality engineers edit, machine shop views, HR data hidden” is easy. “Each supplier sees only its own rows” is hard everywhere and usually paid.
  • How many records, really? Count rows per table today and estimate three years.
  • Which formulas and automations matter? List them. Formulas usually do not survive import, and automations never do.
  • Who will patch it, and how often? All three published many advisories this year. If nobody can upgrade within days of a critical fix, self-hosting is the wrong choice.
  • Where do attachments live? Decide between local disk and S3-compatible storage before the first import.

How each one works

NocoDB: a metadata layer over SQL databases

NocoDB is a Node.js application written in TypeScript, with a Vue frontend. It keeps its own metadata (bases, tables, fields, views, users and permissions) in a database set by NC_DB. If NC_DB is not set, it uses SQLite, which is fine for a laptop trial and wrong for production. In the default setup, tables you create in the UI are created as real tables in that same database. You can also connect external PostgreSQL or MySQL databases as data sources; SQL Server and Oracle are listed as Enterprise only.

The official single-server installer, curl -fsSL https://install.nocodb.com/noco.sh | bash, sets up NocoDB with PostgreSQL, Redis and Traefik with Let’s Encrypt, and writes a docker-compose.yml, a docker.env and an update.sh. It takes flags such as --image-tag, --pg=bundled|external and --redis. The first user to sign up becomes the super admin.

Baserow: Django, Celery and one PostgreSQL table per table

Baserow’s backend is Python and Django with Celery workers, the frontend is Nuxt, and the docs for 2.4.1 list PostgreSQL 14 or newer as supported (15 or newer recommended), pgvector 0.8.1 or newer, and Redis 6.2.7 or newer. The simplest install is one all-in-one image, baserow/baserow, which runs PostgreSQL 15, Redis, Caddy, the backend, the frontend and the workers inside one container and keeps everything under /baserow/data. The docs strongly recommend an external PostgreSQL for production. There is also a multi-container Docker Compose file, a Helm chart and standalone images for horizontal scaling.

The most important design fact is in Baserow’s own decision record on backups: “Baserow creates an actual Postgres database table per Baserow table.” That makes direct SQL reporting possible, and it also means a busy instance can have a very large number of PostgreSQL tables, which affects backups.

Teable: NestJS, Next.js and PostgreSQL first

Teable’s backend is NestJS and its frontend is Next.js, both in TypeScript, with real-time collaboration built on ShareDB. It uses PostgreSQL for both its metadata and the data, Redis for caching and queues, and optional S3-compatible storage with separate public and private buckets for attachments. Each Teable table maps to a physical PostgreSQL table; the metadata schema stores a db_table_name for every table.

The standalone Docker Compose guide runs three containers: postgres:15.4, redis:7.2.4 and the Teable app on port 3000. There is no preset admin account; the first user to sign up becomes the instance admin. The guide also says HTTPS is needed for large copy operations in the browser.

Data model: what a “base” really is

NocoDB

NocoDB organises work into workspaces, bases, tables, fields and views. Field types include links, lookups, rollups, formulas, attachments, and since this year UUID and Auto Number fields. The April 2026 link rewrite matters for migrations: LTAR V2 stores every relation type through a junction table, the legacy Links field is deprecated, and linked-record search now matches only the display value. 0.301.0 also made a breaking API change: API paths must use IDs rather than base or table names, so old scripts that called tables by name need updating.

When NocoDB sits on an external database, it shows those tables as they are, with their own types and constraints. That is its strength and also its risk: an editable grid on an ERP table is a fast way to bypass the ERP’s business rules. Connect read-only accounts unless you are sure.

Baserow

Baserow has workspaces, databases, tables, fields, rows and views, plus applications built with the Application Builder and workflows built with the automation builder. Field types include link to table, lookup, rollup, formula, file, single and multiple select, collaborator, created by, and, from 2.4.0, a button field. Grid, gallery and form views are in the open-source core. Kanban, calendar and timeline views are registered by the Premium code, as are row comments, personal views, row colour decorators, AI fields and JSON, XML and Excel exports. CSV export is in the core.

Since each Baserow table is a PostgreSQL table, you can point a reporting tool at a read replica and query the data. Column and table names in PostgreSQL are internal identifiers, not the friendly names users see, so plan a mapping or use the API for anything user-facing.

Teable

Teable has spaces, bases, tables, fields, records and views, with roles of Owner, Creator, Editor, Commenter and Viewer. Its pitch is that the data is plain PostgreSQL, so you can use SQL tools on it, and that the UI stays responsive on large tables. Imports infer field types: the Excel importer predicts types from the first 5,000 rows, and the Google Sheets importer drops values that do not fit the inferred type. That second point is easy to miss and can cost you data quietly.

API, automation and integrations

  • NocoDB gives every base a REST API with Swagger documentation, API tokens, webhooks (with custom payloads in the Community edition since 0.301.0), and an MCP server for AI clients. Automations have become a larger part of the product this year. 2026.10.0 added the ability to run an automation from a button, but not in the Community edition, and the 2026.10.1 notes describe a security fix for server-side JavaScript execution through webhook templates, which tells you webhooks are powerful enough to need care.
  • Baserow generates REST API documentation for each database, uses database tokens with per-table permissions, supports webhooks, and since 2.0 has a built-in automation builder with triggers and actions, including an AI agent action. 2.4.0 added a trigger that starts a workflow when an email arrives. The Application Builder lets you build simple internal apps and portals on the same data, and since 2.4.1 it is supported for production.
  • Teable offers a REST API with personal access tokens and a plugin system, and its source has a newer V2 API alongside the original one. Its fuller self-hosted deployment adds AI chat, an App Builder and sandboxes for running code. Its cloud plans document an API rate limit of 10 requests per second; we did not find a documented default for self-hosted instances.

For Malaprabha, the two email automations are easy to rebuild in any of the three. Anything bigger, such as pushing NCRs into the ERP, belongs in a workflow tool you already patch and monitor.

Security, sign-in and permissions

Who can sign in, and how

  • NocoDB Community supports email and password sign-in, invite-only sign-up through NC_INVITE_ONLY_SIGNUP, and Google sign-in through NC_GOOGLE_CLIENT_ID and its secret. SAML and OIDC single sign-on are documented for the Business and Enterprise plans, and the docs ask you to contact sales for SSO. SCIM is listed for Enterprise. When we searched the public source tree at 2026.10.1, we did not find a SAML implementation, which fits the docs: the paid features are not in the public repository.
  • Baserow supports email and password, TOTP two-factor authentication since 2.0, and an admin option to remove a user’s 2FA since 2.3.0. Its SSO overview says SSO is available on the Advanced and Enterprise plans and needs an activated licence. Supported protocols are SAML 2.0 (with dedicated guides for Okta, OneLogin and Entra ID), OAuth 2.0 (Google, Facebook, GitHub, GitLab) and generic OpenID Connect. Admins can disable password login. The SSO code lives in the enterprise/ folder of the repository.
  • Teable supports email and password, GitHub, Google and generic OIDC through environment variables such as SOCIAL_AUTH_PROVIDERS=oidc and BACKEND_OIDC_*, and PASSWORD_LOGIN_DISABLED=true to force SSO. The OIDC code is present in the AGPL backend source at the 1 November tag. We did not run the community image, so we cannot confirm that OIDC is enabled there without a licence. Teable’s cloud spaces need the Business plan for SSO.

There is one warning that two of the three vendors now spell out. Teable’s docs say the identity provider must verify email addresses, because Teable links an OIDC login to an existing account with the same email. Baserow’s docs say it trusts the email reported by the provider, and its 2.4.0 release added a check for verified email before binding an OAuth or OIDC login to an existing account. Whichever tool you choose, configure the identity provider so that users cannot set an unverified email address, or someone may sign in as the plant head.

Permissions

  • NocoDB has role-based access at workspace and base level in the Community edition, with roles that range from creator to viewer. Row-level security, audit logs and SSO are listed for paid plans.
  • Baserow has workspace members and admins in the open core. Role-based permissions per workspace, database and table, teams, audit logs and field-level permissions are in the enterprise feature list in the source. 2.4.0 added field permissions for specific users and teams, which helps with the HR sheet in our scenario.
  • Teable has Owner, Creator, Editor, Commenter and Viewer roles. Its “Authority Matrix”, which controls access at field, record and view level, is a paid feature.

For Malaprabha, the HR contract labour sheet is the hard case. Bank account digits should not sit in the same base as NCRs. The simple answer, in any of the three, is a separate base or workspace with a small member list, not a clever field permission.

The advisory record

All three projects published many advisories this year, and the record is more useful as a lesson than as a score. Counts depend on how actively a project invites and publishes reports, so a large number can also mean a project that takes reports seriously.

  • NocoDB: the two critical 2026 advisories are an RCE through SQL injection in the formula parse tree, fixed in 2026.09.0 and published on 2 November, and cross-base database access through a source identifier collision, fixed in 2026.08.1. Others in the same period include SQL injection through select option titles and server-side JavaScript execution through webhook templates (both fixed in 2026.10.1), account takeover through invitation resend and exposure of the metadata database through a client-controlled source flag (both fixed in 2026.10.0), exposure of a TLS client private key (2026.09.0), many bypasses of shared-view row filters (2026.08.0) and SSRF through remote fetch in integrations.
  • Baserow: unauthenticated data exposure in the Application Builder (high, fixed in 2.3.1), a cross-workspace IDOR and formula injection in exports (2.3.0), stored XSS through SVG on public forms (2.2.2), password reset token reuse (2.2.1), SSRF in PostgreSQL data sync and path traversal in workspace import (2.2.0).
  • Teable: the 13 October batch included a V2 REST API without resource-level authorization that allowed access across tenants, SQL injection in base import, a bypass of share passwords, a plugin that could obtain database connection credentials, and stored XSS leading to session hijack. Earlier, in August, an arbitrary file write as root through path traversal in attachment presigned paths was published.

The patterns repeat. Formulas and field options become SQL somewhere, so injection keeps appearing. Shared views and public forms are the parts most exposed to strangers, so filter bypasses and XSS keep appearing there. Imports and data syncs fetch from URLs, so SSRF and path traversal keep appearing. For Malaprabha this gives three rules: keep the instance off the public internet unless a public form is truly needed, treat every share link as public, and keep imports and data syncs for admins only.

Quality and HR records are personal data

NCRs name inspectors and supervisors, supplier ratings name contacts with phone numbers, and the contract labour sheet holds names and bank digits. In India, the Digital Personal Data Protection Act, 2023 and its rules shape how such data should be handled. This post is not legal advice. In practice it means knowing what is stored, limiting who can see it, deleting what you no longer need, and answering an auditor’s questions about access and backups. Self-hosting answers “where”; it does not answer “who” and “how long”.

Performance and capacity

None of the three publishes independent benchmarks that we could verify, and we did not run load tests. Treat every number in this section as the vendor’s own guidance.

  • NocoDB docs (updated 3 October 2026) give a minimum of 2 vCPU, 2 GB RAM and 10 GB disk, and recommend 4 vCPU, 8 GB RAM and 50 GB or more of disk for production. The default attachment size limit, NC_ATTACHMENT_FIELD_SIZE, is 20 MiB.
  • Baserow does not give a single sizing figure in the Docker guide we read. It documents a stateless deployment for horizontal scaling, ways to reduce memory by starting fewer internal processes, and a warning to make sure containers always have CPU time because of periodic background tasks. Its backup decision record says large instances can have hundreds of thousands of tables.
  • Teable docs recommend the standalone Docker Compose setup for under 50 users, with at least 2 cores, 4 GB RAM and 40 GB disk. Larger teams are pointed to the Kubernetes or fuller deployments. Teable’s marketing stresses large tables; we did not test those claims.

Malaprabha’s sizes are small: a few thousand NCRs, 140 suppliers, a few hundred patterns and a dispatch table that grows by a few hundred rows a week. Any of the three handles this on a modest VM. The real capacity question is attachments, so measure the Airtable attachment size before choosing a disk.

Licences and editions

  • NocoDB started as Xmysql under MIT in 2017, became NocoDB in 2021, and was under GNU AGPL-3.0 for most of its life. The commit “chore: change to sustainable use license” landed on 8 January 2026, and 0.301.0 on 13 January was the first release under the new terms. The current LICENSE.md says it was updated on 29 January 2026. The Sustainable Use License says: “You may use or modify the software only for your own internal business purposes or for non-commercial or personal use.” It allows distribution only free of charge for non-commercial purposes, and it states that it applies to the master and develop branches. NocoDB’s docs add that offering it as a hosted service to third parties may need a commercial licence. In short: free for internal use, not open source by the OSI definition, and older AGPL releases remain AGPL. Paid plans (Business, Scale, Enterprise) are activated with a licence key in the admin panel, and a licensed install contacts NocoDB’s licence server every six hours unless you use the airgapped licence.
  • Baserow’s LICENSE file says the Baserow Open Source Edition is MIT (Expat), client-side JavaScript is MIT, the docs/ folder is CC BY-SA 4.0, and the premium/ and enterprise/ folders have their own licences. The Premium licence says the code “may only be used in production” with a valid subscription for the correct number of users, and allows copying and modifying for development and testing. Self-hosted plans are Premium, Advanced and Enterprise, priced per user; check the vendor’s current self-hosted price list rather than the cloud page.
  • Teable’s LICENSE puts apps/nestjs-backend and apps/nextjs-app under AGPL-3.0 and the packages/ folder under MIT, with additional terms under section 7(e) of the AGPL that forbid modifying, replacing or removing Teable brand assets. A self-hosted licence is bound to an instance ID stored in the database. Editors and above are billable seats, commenters and viewers are free, there is a seven-day grace period, and when a licence expires the instance falls back to the basic version with data kept.

Vendor cloud prices, as listed on their pricing pages when we checked, for orientation only: NocoDB’s cloud plans start with a free tier and paid Plus, Business and Scale plans priced per seat; Baserow’s cloud Premium starts at 10 US dollars per user per month billed annually and Advanced at 18; Teable’s cloud Pro is 13 US dollars per seat per month billed annually and Business is 20. Self-hosted prices can differ, and these change often.

For Malaprabha: Baserow’s MIT core and Teable’s AGPL community edition are open source, and using either internally, unchanged, creates no duty to publish code. NocoDB also allows internal use, but “internal business purposes” is a narrower promise than an open-source licence, so legal should read it.

Operations and day two

Install

  • NocoDB: the single-server script is the quickest path and gives you PostgreSQL, Redis and HTTPS through Traefik. Pin the image tag with --image-tag instead of latest, as the docs advise. Set NC_AUTH_JWT_SECRET yourself (otherwise a random one is generated) and set NC_CONNECTION_ENCRYPT_KEY before you connect any external database, because without it the credentials of external data sources are stored as plain text in the metadata. Turn off telemetry with NC_DISABLE_TELE if your policy needs it.
  • Baserow: the all-in-one image is one docker run with a volume for /baserow/data and BASEROW_PUBLIC_URL set, and Caddy handles HTTPS. For production, use the Docker Compose file or point the all-in-one image at an external PostgreSQL with DATABASE_URL. The Compose file refuses to start unless SECRET_KEY, DATABASE_PASSWORD and REDIS_PASSWORD are set, which is a good default.
  • Teable: the standalone Compose setup needs a .env file. The example ships placeholders such as POSTGRES_PASSWORD=replace_this_password and SECRET_KEY=replace_this_secret_key, and PUBLIC_ORIGIN must match the URL users open. The example also publishes PostgreSQL on host port 42345; remove that mapping unless you need it, or bind it to localhost.

In all three, the first account created becomes the administrator. Create it yourself immediately after the first start, before the URL is shared with anyone.

Upgrades

  • NocoDB ships about two releases a month, and the installer writes an update.sh. Read the release notes for “breaking” and self-hosting sections every time; this year they included API path changes, the LTAR V2 link rewrite and the new behaviour of secure attachments. Use GET /api/v1/health in your monitoring.
  • Baserow applies all database migrations on startup, and the Docker guide says you can jump straight to the latest version without intermediate releases; it gives 1.23.2 to 2.4.1 as an example. The exception is the embedded PostgreSQL: images before 1.24 shipped PostgreSQL 11 and newer ones ship 15, so an old data volume must be upgraded once with the documented pgautoupgrade step before a new image will start.
  • Teable releases several times a week. Its upgrade guide asks you to pin image tags on Kubernetes, warns that newer versions no longer fall back to built-in default secrets (the first start after upgrade stops and lists the variables you must set), and says rolling back after a schema migration may be unsafe, so you should restore from backup instead. Pick a fixed rhythm, such as every two weeks plus any security release, and stick to it.

Backups

  • NocoDB docs recommend, at minimum, a daily pg_dump of the database and a tarball of the attachments folder, or S3 storage with its own versioning. Litestream backup is only for SQLite setups.
  • Baserow offers two documented methods. The first copies the whole /baserow/data volume with tar while Baserow is stopped; it covers the embedded PostgreSQL data directory, Caddy certificates and uploaded files, but not an external database or external file storage. The second uses Baserow’s own command, backend-cmd-with-db backup, which writes a portable backup of the database. That command exists because a plain pg_dump must hold a lock on every table in one transaction, and Baserow can have a very large number of tables; its decision record explains the trade-off. Both methods are documented as best done when the instance is not in use.
  • Teable docs list three options: a VM-level backup, a tar of the Docker volumes, or pg_dump of PostgreSQL plus the Redis RDB file plus the teable-data volume. If you use S3 storage, back up the buckets too.

Whatever the tool, a backup is only proven by a restore: restore to a second VM, open three records with attachments, and check that a link still points to the right row.

Migration from Airtable or Google Sheets

NocoDB’s Airtable importer

NocoDB imports from Airtable using a shared base or view URL and a personal access token with at least the data.records:read scope. You can import into the default data source or an external one. Its docs (updated 9 October 2026) are honest about the limits. Formula fields are not imported. When you import from a shared view rather than a base, links become text, lookups become long text, rollups and formulas become static values, and gallery, kanban and calendar views become grids. The importer produces a report of skipped, approximated and failed items that you can download as CSV. Keep that CSV; it is your to-do list.

Baserow’s Airtable importer

Baserow imports from a public share link to a whole base or, since 2.4.0, a publicly shared view. If the Airtable organisation blocks unauthenticated access to share links, Baserow’s docs describe pasting the Airtable session cookies into the import form. Treat those cookies like a password, use them once, and sign out of Airtable afterwards. The import adds a table called “Airtable import report” listing what was not imported or was imported only partly.

Baserow’s docs list what transfers: tables and records, most field types, links between tables, attachments, and grid views with filters, sorts and grouping. They also list what does not: formula, lookup, rollup, collaborator, created by, last modified by, button and barcode fields; automations, interfaces, integrations, row comments, revision history, field descriptions and access controls. Currency becomes a number with a prefix, and percent a number with a suffix. The docs suggest converting important computed fields to plain text or number in a copy of the Airtable base before import, so you keep the values while you rebuild the logic.

Teable’s importers

Teable imports CSV and Excel files (Excel up to 5 MB, with types predicted from the first 5,000 rows) and Google Sheets (up to 300 columns per tab, dropping values that do not fit the inferred type). Its Airtable import works “if Airtable integration is configured for your instance”, and can also bring over view filters, sorts and grouping if you give it a read-only shared base link, because Airtable’s API does not expose view settings. Teable also documents an AI chat based migration called Connect Everything, which can move data from Airtable, Baserow or NocoDB; it depends on the AI features being set up.

From Google Sheets

For the dispatch tracker, merge the per-customer tabs into one table with a “customer” column, export to CSV, import once, and then stop editing the sheet. Two live copies for more than two weeks usually means two versions of the truth.

What does not move, whichever tool you choose

  • Formulas. Plan to rewrite every formula, and test each against ten known records.
  • Automations and scripts. Airtable automations, scripting blocks and interface pages do not import anywhere.
  • Comments and revision history. Expect to lose them, or export them separately for the record.
  • Permissions and share links. Rebuild access from a written list, not from memory.
  • Integrations. Anything that calls Airtable’s API, including Zapier or Make scenarios, must be pointed at the new API, which has different IDs and paths.
  • Attachment URLs. Links to Airtable attachment URLs in emails or documents will not point to the new copy.

Side by side

Best fit

  • NocoDB: a spreadsheet interface over existing PostgreSQL or MySQL databases, and teams that want an Airtable-like tool for internal use and accept a fair-code licence.
  • Baserow: a self-contained Airtable replacement with an MIT core, an Application Builder and automations, for teams that want the most mature importer.
  • Teable: PostgreSQL-first teams that want SQL access to their no-code data, real-time collaboration and an AGPL community edition.

Data and API

  • NocoDB: external data sources, REST API by ID, webhooks, MCP server.
  • Baserow: one PostgreSQL table per table, per-database API docs, database tokens, webhooks, automation builder.
  • Teable: physical PostgreSQL tables, REST API with access tokens, plugins, real-time updates.

Sign-in

  • NocoDB: email and Google in Community; SAML and OIDC on Business and Enterprise.
  • Baserow: email and TOTP in the open core; SAML, OAuth2 and OIDC on Advanced and Enterprise.
  • Teable: email, GitHub, Google and OIDC configured by environment variables; check which work without a licence on your image.

Migration

  • NocoDB: Airtable via token and shared link; no formulas; CSV report.
  • Baserow: Airtable via public link; no formula, lookup or rollup fields; report table.
  • Teable: CSV, Excel, Google Sheets, Airtable when configured; type inference can drop values.

Operations

  • NocoDB: one-script install, about two releases a month, many advisories this year.
  • Baserow: all-in-one image or Compose, monthly to quarterly releases, documented backup command.
  • Teable: Compose or Kubernetes, several releases a week, rollback by restore only.

Licence

  • NocoDB: Sustainable Use License since January 2026; source-available.
  • Baserow: MIT core; Premium and Enterprise folders under commercial licences.
  • Teable: AGPL-3.0 apps and MIT packages, with brand terms; paid features by licence key.

A worked plan for Malaprabha

Month 1: decide what the bases are for

  • Write one page per Airtable base: purpose, owner, tables, which fields are entered and which are calculated, who edits, who views, and which formulas and automations matter.
  • Count records and measure attachment size per base. Export each base to CSV as a frozen copy for the record.
  • Move the contract labour sheet out of scope. HR data belongs in the HR system or a separate, tightly held base, not in the quality tool.
  • Clean the NCR base in Airtable first: archive closed NCRs older than three years into an export, delete unused views, and convert the “days open” formula to a documented rule.

Month 2: build a test instance

  • Create a VM with 4 vCPU, 8 GB RAM and a separate disk sized for attachments plus growth. Install Baserow 2.4.1 with Docker Compose and a dedicated PostgreSQL, behind the company’s reverse proxy, reachable only from the office network and VPN.
  • Import the NCR and CAPA base from a public share link, read the import report table, and fix links, formulas and the two automations by hand. Record each fix.
  • In parallel, install Teable’s community image on a second throwaway VM and import the same base, so the team can compare with real data rather than screenshots.
  • Back up with backend-cmd-with-db backup, restore to a third VM, and check five NCRs with photos.

Month 3: pilot with real work

  • Run new NCRs in the pilot tool for one product line and one customer for four weeks, with Airtable read-only for that scope.
  • Rebuild the supervisor form, test it on the phones the supervisors actually use, and confirm the photos upload on the shop floor Wi-Fi.
  • Decide the sign-in question. If the plant head wants Google Workspace sign-in for everyone, price Baserow Advanced for the editors and compare with Teable’s OIDC on the image you would run.
  • Subscribe the IT team to the GitHub security advisories of the chosen project and book an upgrade slot every fortnight.

Months 4 to 6: move the rest, one base at a time

  • Move supplier ratings next, then tooling and patterns, then the dispatch tracker from Google Sheets.
  • Close the Airtable workspace only after one full month in which nobody needed to open it, and keep the final CSV exports with the quality records.

What we do not recommend for Malaprabha

  • Exposing the instance to the internet for supplier access in the first six months. If suppliers must fill forms, use a single public form and nothing else.
  • Connecting NocoDB to the ERP’s MySQL database with a writable account. A read-only view for sales is a reasonable later project; editing ERP tables from a grid is not.
  • Turning on AI features before deciding which provider receives quality and supplier data.
  • Running on the latest tag of any of the three.

When not to adopt each

  • Do not pick NocoDB if your legal team needs an OSI-approved licence, if you plan to offer the tool to customers or partners as a service, or if you cannot keep up with roughly two releases a month and a heavy advisory record.
  • Do not pick Baserow if kanban, calendar or timeline views are essential and you will not pay for Premium, if single sign-on is mandatory and you will not pay for Advanced or Enterprise, or if you need a spreadsheet interface on an existing database rather than a new one.
  • Do not pick Teable if you cannot upgrade often, if you need predictable version numbers for change management, or if the features you need sit in the paid plan and the budget is not there.
  • Do not self-host at all if nobody owns patching within days of a critical advisory, nobody tests restores, or the data is small and simple enough for a shared spreadsheet with sensible permissions. A hosted plan from the same project may cost less than the risk.

A short history

  • NocoDB: the repository was created on 29 October 2017 for Xmysql, a tool that generated a REST API from a MySQL database, under MIT. In May 2021 the project announced “Xmysql is now NocoDB” and grew into a spreadsheet interface over SQL databases, mostly under AGPL-3.0. It became one of the most starred Airtable alternatives on GitHub. In January 2026 it moved to the Sustainable Use License, and in April 2026 to date-based versions.
  • Baserow: copyright in its licence starts in 2019, and its GitLab project was created on 15 February 2019. It was built as an open-source, self-hostable no-code database on Django and Nuxt, added Premium and Enterprise editions later, and in 2.0 (November 2025) grew into a platform with automations and an AI assistant. Development moved to GitHub, and 2.4.1 in October 2026 made the Application Builder production-ready.
  • Teable: the repository was created on 1 November 2022, with copyright from 2023. It set out to be an Airtable alternative built on PostgreSQL that scales to large tables, and in 2026 added AI chat, an App Builder and a fuller self-hosted deployment.
  • Others we looked at: Grist’s grist-core is under Apache-2.0, its repository was created in May 2020, and v1.7.22 came out on 29 October 2026. It is a strong choice for spreadsheet-style work with Python formulas, but it is a different model from Airtable, so it deserves its own post. Its advisories this year included a critical remote code execution through prototype pollution from an imported document, fixed in 1.7.19.

A simple decision guide

  • Do you want a spreadsheet view on top of an existing PostgreSQL or MySQL database, for internal use, and can you accept a fair-code licence? Choose NocoDB.
  • Do you want a complete, self-contained Airtable replacement with an MIT core, a detailed importer and an Application Builder, and can you pay for Premium views or SSO if needed? Choose Baserow.
  • Do you want your no-code data in plain PostgreSQL with SQL access and real-time editing, and can your team upgrade often? Choose Teable.
  • Must the licence be OSI open source with no commercial folders at all? Look at Teable’s community image or Grist, and read what is left out.
  • Can nobody patch within days of a critical advisory? Use a hosted service.

Checklist before go-live

  • One page per base: purpose, owner, tables, calculated fields and who sees what.
  • Personal data identified, HR and finance data kept out or in a separate, restricted base.
  • First admin account created by IT before the URL is shared, and open sign-up turned off or limited to invites.
  • Secrets set by you: NC_AUTH_JWT_SECRET and NC_CONNECTION_ENCRYPT_KEY for NocoDB, SECRET_KEY, DATABASE_PASSWORD and REDIS_PASSWORD for Baserow, SECRET_KEY and the database and Redis passwords for Teable.
  • Image tag pinned to a known version, not latest.
  • Instance reachable only from the office and VPN, unless a public form is required, and then only that form.
  • Sign-in tested, including a removed user who must fail to log in and an identity provider that only sends verified emails.
  • Public share links reviewed and each one given an owner and an expiry date.
  • Backups of database and attachments every night, copied off the host, and one restore tested on a second machine.
  • Import report reviewed by the base owner, with a written list of fixes.
  • Advisory feed subscribed and an upgrade slot booked every fortnight.
  • Retention and deletion rules for each base agreed and written down.

Common mistakes

  • Importing everything. Old views, dead fields and closed records from 2021 slow people down. Start clean.
  • Trusting formulas after import. Most formulas do not move. Check every calculated column against known answers.
  • Leaving SQLite in production. NocoDB uses SQLite when NC_DB is not set. That is for trials only.
  • Forgetting attachments in backups. A database restore without the files gives you records with broken photos.
  • Sharing a view as a quick fix. This year’s advisories show that shared views and public forms are the most attacked parts of these tools.
  • Linking SSO to accounts by unverified email. Make the identity provider verify emails before you enable automatic linking.
  • Missing the licence change. NocoDB in 2026 is not under the licence it had in 2025. Read the licence of the version you deploy.

Hands-on check: what we ran and what we did not

We kept this check small, user-level and inside /workspace/revisit/drill108 on our shared Linux box, on 2 November 2026 at about 10:22 PM IST, and it took about ten minutes. We did not start any of the three applications: each needs Docker or a full Node.js or Python stack with PostgreSQL and Redis, and we did not run Docker, install system packages or start services for this post.

What we did:

  • Pulled the release records for NocoDB 2026.10.1, Baserow 2.4.1, Teable release.2026-11-01T07-52-11Z.3675 and Grist v1.7.22 from the GitHub API. None of the four releases carries uploaded assets, so there is no vendor-published checksum to compare against.
  • Downloaded the three GitHub source archives and recorded their SHA-256 values for our own reference: NocoDB 827f72a4...524778, Baserow ac124e1a...6c6182, Teable e590aeb9...1ade. GitHub generates these archives, so the values only prove what we downloaded, not what the vendor signed.
  • NocoDB 2026.10.1: LICENSE.md begins with “Updated on: January 29, 2026”, and packages/nocodb/package.json declares the “Sustainable Use License”. The same file still says version 0.301.3, so do not rely on package.json to tell you which NocoDB release you run. We counted 248 TypeScript files under migration folders in the backend, and a search for SAML found no SSO implementation in the public source, only incidental mentions.
  • Baserow 2.4.1: version.py says 2.4.1. The premium/ and enterprise/ folders each carry their own licence. The core backend has 519 migration files, and the premium and enterprise backends have 99 more. The enterprise feature list names teams, role-based access, SSO, audit log, secure file serving, data sync, advanced webhooks and field-level permissions, among others. The Premium app registers the kanban, calendar and timeline views, row comments and the JSON, XML and Excel exporters. The Compose file defines ten services, uses pgvector/pgvector:pg15, redis:6 and caddy:2.11.4, and refuses to start without SECRET_KEY, DATABASE_PASSWORD and REDIS_PASSWORD. The all-in-one Dockerfile installs PostgreSQL 15.
  • Teable build 3675: the LICENSE matches the AGPL and MIT split described above, the app package.json says 1.10.0, there are 145 Prisma migration files, the metadata schema stores a db_table_name per table, and the AGPL backend contains OIDC strategy and Airtable import modules. We did not find a licence check in the OIDC files we read, but we did not trace the whole code path.

What we did not do: run any of the three applications, test sign-in or SSO, import a real Airtable base, measure performance or test a backup and restore. Those need a proper VM with Docker, a test identity provider and a copy of real data. We deleted the extracted source trees after the check.

Unlearn and re-learn

  • Unlearn: “It is just a spreadsheet with a nicer face.” Re-learn: it is a database with an API, share links and personal data; run it like one.
  • Unlearn: “Every Airtable alternative is open source.” Re-learn: NocoDB moved to a fair-code licence in 2026, Baserow mixes MIT with commercial folders, and Teable mixes AGPL with paid features; read the licence of the version you deploy.
  • Unlearn: “The importer will move my base.” Re-learn: importers move tables, records and links; formulas, automations, comments and permissions are yours to rebuild.
  • Unlearn: “A self-hosted tool can be left alone once it works.” Re-learn: this year’s advisories show that these tools need patching every few weeks, like any other web application.

Sources

comments powered by Disqus

Releted Posts

Self-hosted project tracking in 2026: revisit Plane, OpenProject and Redmine before you move another backlog off Jira

Many Indian software teams did not choose Jira so much as inherit it. Somebody set up a Jira Server licence in 2016, it moved to Data Center when Server ended, and ten years later it holds every bug, every sprint, every customer escalation and half the reasons behind old design decisions.

Read more

Self-hosted wikis in 2026: revisit BookStack, Wiki.js and Outline before you write another runbook in a shared drive

Ask any support engineer in a growing Indian company where the runbook for a failed nightly job lives, and you will usually get three answers.

Read more

Workflow automation in 2026: revisit n8n, Node-RED and Activepieces before you wire another business process to a webhook

Most teams first meet workflow automation as a shortcut: draw a few boxes, point a webhook at a SaaS, and declare the process automated.

Read more