n8n + Baserow: self-hosted database for your automations

A need keeps coming up in automation projects: giving a non-technical team an interface to view or manually fix the data a n8n workflow produces — a list of AI-qualified leads, a case-tracking log, a content catalog. A Google Sheets tab works at first, until formulas break and two people overwrite the same row at once. Supabase solves the structure problem, but exposes SQL to people who have never written any. Between the two sits Baserow: an open-source relational database with a spreadsheet-like interface, a native n8n node, and the option to host it entirely on your own infrastructure.

What Baserow is, and why pair it with n8n

Baserow looks like Airtable — typed columns, filtered views, entry forms — but runs on PostgreSQL and deploys with a single Docker command on your own VPS. For a team already committed to self-hosting (see our guide on choosing a VPS for self-hosted n8n), it's the missing piece for giving data a real interface without a single byte leaving your infrastructure for a third-party US service — an argument that matters as much for GDPR compliance as for cost control, since the self-hosted free tier has no artificial row cap.

n8n ships a native Baserow node (n8n-nodes-base.baserow) that has been around for several versions, with a notable update in March 2026: batch operations (create, update and delete multiple rows in a single request instead of looping), extra filters on the Get Many operation, and simplified API token authentication. No community node to install, no third-party maintenance to track — unlike some integrations covered elsewhere on this blog that rely on unofficial packages.

Self-hosting Baserow

The official image starts as a single Docker container bundling PostgreSQL, Redis and the application:

docker run -d --name baserow \
  -e BASEROW_PUBLIC_URL=https://baserow.your-domain.com \
  -v baserow_data:/baserow/data \
  -p 8080:80 \
  baserow/baserow:1.32

If you already expose n8n behind a reverse proxy, the same principle applies here — see our guide on setting up n8n over HTTPS with Traefik or Caddy — to get an automatic TLS certificate on baserow.your-domain.com instead of exposing raw port 8080. On an instance already hosting several services (n8n, Baserow, possibly Supabase), keep separate backup volumes: an accidental restore of one should never overwrite the other.

Generating the API token and wiring the credential

From the Baserow account menu (bottom-left → Settings → API tokens), create a token dedicated to n8n rather than reusing your personal one — one token per integration lets you revoke a single workflow's access without cutting off everything else. In n8n, the Baserow API credential only asks for two fields: the instance URL (the API responds under /api/) and that token. As with any integration key, store it exclusively in the encrypted n8n credential — our guide to securing API credentials covers the basics if your instance isn't locked down on this yet.

The Baserow node: operations and batch mode

The node exposes the usual operations — Create, Get, Get Many (with per-field filters, sorting and pagination), Update, Delete — applied to a table identified by its numeric ID (visible in the table's URL inside the Baserow interface). Since the March 2026 update, Create accepts an array of objects to insert multiple rows in a single call: useful when a workflow processes a batch of items (a PDF invoice extraction producing several line-item rows, for example) instead of one item at a time, which cuts down the number of requests and the risk of hitting a rate limit.

One thing that often trips people up on the first try: Single Select and Link to Table fields expect the internal ID of the option or linked row, not its display label. A prior Get Many call on the reference table, filtered by the displayed label, resolves that ID before the write — the same pattern described in our Compare Datasets node guide for matching two datasets against each other.

A concrete case: an AI-fed lead tracker

Consider a full scenario, consistent with the workflows already covered on this blog. A multi-step form collects an inbound request; an LLM call qualifies the lead (score, identified need, urgency) and enriches it automatically (industry, company size via a web search); the Baserow Create node inserts a row into a Leads table with those fields already filled in. The sales team opens Baserow, filters the view for scores above a threshold, and works directly in an interface they already know, without ever touching n8n or a SQL database.

This is exactly the argument documented in end-user software engineering research: a landmark synthesis by Ko et al. (2011), The State of the Art in End-User Software Engineering, published in ACM Computing Surveys, shows that users without programming training make significantly fewer errors and learn faster when working with visual, constrained structures (typed columns, forms, filtered views) rather than code or free-form queries. Giving a sales team a Baserow view instead of read access to Supabase isn't a cosmetic detail — it's what keeps a misunderstood value from turning into a silent error in the sales pipeline.

Triggering n8n from Baserow (the reverse direction)

The flow also works the other way. Baserow exposes per-table webhooks, configurable on the rows.created and rows.updated events, with an optional filter on which fields must change to fire the call. A sales rep who manually flips a lead's status to "Meeting booked" in the Baserow interface can trigger an n8n Webhook Trigger that sends a Slack alert to the team, following the same logic as our guide on multi-source digests — except here the manually editable source of truth is Baserow, not a Supabase table opaque to anyone who doesn't write SQL.

Baserow, Data Tables, Google Sheets or Supabase: when to pick which

These four options aren't interchangeable:

n8n Data Tables — for internal workflow state (deduplication, cache, queue) that nobody needs to view directly. No dedicated interface, no access from a Code node, 50 MB cap by default.
Google Sheets — for a one-off need or a few hundred rows, with no concurrent-write conflicts. Worth remembering: Panko (1998), in his landmark study What We Know About Spreadsheet Errors published in the Journal of Organizational and End User Computing, puts the cell-level error rate of large spreadsheets at 1 to 6% — a useful reminder before building a critical process on a spreadsheet rather than on typed, validated columns.
Baserow — as soon as a non-technical person needs to view, filter or manually fix the data, with real relational structure and a self-hosting requirement.
Supabase — for large volumes, complex queries, or when the data never needs to leave the technical perimeter (RAG, logging, high-throughput queues).

Common pitfalls

One API token for every workflow. If it leaks or a workflow misbehaves, there's no way to revoke access without cutting off every integration. One token per workflow or use case limits the blast radius.
Sending labels instead of IDs on linked fields. A text value sent to a Single Select or Link to Table field fails silently or creates a duplicate option depending on the field's configuration — always resolve the ID first.
Forgetting webhooks on manual edits. If someone corrects a row directly in Baserow, only rows.updated events with the right field filter trigger the rest of the pipeline — check this configuration rather than assuming it captures every change.

Going further

The lead tracker described here fits naturally alongside the sorting and urgency scoring in the AI Inbox Pack (€79): sorted, prioritized emails feed the same Baserow table as leads coming from a form, for one unified sales view. If your data volume or semantic search needs outgrow what Baserow can offer, the RAG Assistant Pack (€119) takes over with a real Supabase vector database. The Complete FlowKit Bundle (€269) brings all three packs together for anyone who wants to cover the full chain, from an inbound email to a sales pipeline visible to the whole team.