Self-Hosting a Low-Code Database on Raspberry Pi: Baserow and NocoDB for Shop Inventory Tracking

Most maker shops end up tracking inventory the same way: a spreadsheet that starts clean and slowly rots into merged cells, inconsistent units, and a filament column nobody trusts. A spreadsheet is a grid; what shop inventory actually needs is a lightweight database — linked tables (a spool links to a supplier, a project links to the parts it consumed), form-based data entry so restocking doesn't require opening a terminal, and views that filter to "below reorder threshold" without a manual sort every time. That's exactly the gap that self-hosted low-code database tools fill, and a Raspberry Pi is more than capable of running one for a single shop's workload.

Baserow vs NocoDB

Both projects occupy the same niche — an Airtable-style grid-and-forms interface on top of a real relational database — but they get there differently, which matters for which one fits your setup better.

BaserowNocoDB Core ideaPurpose-built spreadsheet-database hybrid, own data modelTurns an existing database (Postgres, MySQL, SQLite) into a no-code UI layer on top Backing databasePostgreSQL (bundled in the self-host Docker image)Your choice — can point at a database you already run, or use its bundled SQLite for a simple setup ViewsGrid, gallery, kanban, calendar, formGrid, gallery, kanban, calendar, gantt, form Best fitStarting fresh with no existing database, want the cleanest built-in UIYou already have (or want) a Postgres/MySQL instance, or want a no-code front end over data other services also write to Resource footprint on a PiModerate — Postgres plus the app backendLight with SQLite, moderate with an external Postgres backend

Hardware and Prerequisites

Either tool is comfortable on a Raspberry Pi 4 or 5 with 4GB of RAM or more; 2GB will technically run either but leaves little headroom if you're also running other self-hosted services on the same Pi. Run from an SSD over USB3 (on a Pi 4) or NVMe (on a Pi 5 with a HAT) rather than a microSD card — a relational database doing frequent small writes is exactly the workload that wears out SD cards fastest and produces the most noticeable slowdowns as the card degrades. Docker and Docker Compose are the simplest install path for both projects and are what their own documentation leads with.

Installing Baserow

1. Install Docker and Docker Compose on Raspberry Pi OS (64-bit) if not already present.
2. Pull Baserow's official all-in-one Docker image, which bundles the backend, frontend, and an embedded Postgres instance for the simplest single-container start, or use their multi-container Compose file if you want Postgres managed separately for easier backups.
3. Mount a persistent volume for Baserow's data directory outside the container so upgrades don't wipe your tables.
4. Start the container, confirm it's reachable on the Pi's local port, and complete the first-run admin account setup from a browser on your network.
5. Create your first database, then your first table — for shop inventory, start with fields for item name, category, quantity on hand, reorder threshold, unit cost, and a linked field to a Suppliers table rather than a free-text supplier name, which is where the relational structure starts paying off over a spreadsheet.

Installing NocoDB

1. Decide on a backing database first: point NocoDB at an existing Postgres or MySQL instance if you already run one (for example, one already backing another self-hosted service on the same Pi), or let it use its default SQLite store for a standalone, simpler setup.
2. Run the official NocoDB Docker image via Compose, mounting a persistent volume for its metadata store and, if using SQLite, the database file itself.
3. On first run, NocoDB will either connect to your specified external database or create its default store, then walk you through creating your first base (NocoDB's term for a project/database grouping).
4. Build your inventory tables the same way as above — NocoDB's strength shows up if you later want other tools or scripts to read the same underlying database directly via SQL, since the no-code layer sits on top of a normal database rather than its own proprietary store.

A Practical Shop Inventory Structure

TableKey FieldsNotes ItemsName, category, quantity on hand, reorder threshold, unit, barcode/SKULink category to a lookup table instead of free text for consistent filtering SuppliersName, contact, lead time, websiteLinked from Items so reordering has a one-click path to "who do I buy this from" Restock LogDate, item (linked), quantity added, cost, supplier (linked)Gives you real purchase history instead of guessing consumption rate Low Stock ViewFiltered view of Items where quantity < reorder thresholdThe actual payoff — a live, always-current shopping list rather than a manual spreadsheet sort

Both tools support basic automations or webhooks (naming and depth vary by version) that can fire an email or a notification when a row crosses a threshold — worth setting up once your table structure is stable, so a low-stock alert reaches you without having to remember to check the dashboard.

Backup and Access

This is now a database holding business-relevant data, so treat it with the same backup discipline as any other self-hosted service — regular snapshots of the Postgres volume (or the SQLite file, if that's your backend) using the same restic or Borg-based backup approach already common for other self-hosted Pi services, stored off the Pi itself. Don't expose the admin interface directly to the internet; if you want to check inventory from outside your shop's network, put it behind a VPN like Tailscale rather than forwarding a port, since both tools' admin panels are a reasonable target if left open and under-patched.

Safety

The main risk here isn't physical — it's data loss from skipping backups on what quietly becomes the single source of truth for your parts and consumables. Confirm your backup job actually runs and actually restores before you trust it; the correct order is "build the database, build the backup, test the restore," not the other way around after the database already represents months of purchase history.

Either tool turns an SD-card-killing spreadsheet habit into a structured, linked, filterable inventory system that a Raspberry Pi running Docker can host for the lifetime of your shop — the choice between them mostly comes down to whether you'd rather start with a clean purpose-built data model (Baserow) or a no-code layer over a database you control directly (NocoDB).