What a local inventory database looks like in practice

Spreadsheets vs. enterprise warehouse software

Spreadsheets work until someone overwrites a quantity cell. The old value is gone, and there is no record of what changed or why. Sort the sheet by a different column and formulas tied to specific rows break silently. For a shop with 50 items this is manageable. For 500 items across three storage locations, the spreadsheet becomes a liability.

Enterprise ERPs like NetSuite, Katana, and Fishbowl cost $300 to $1,000+ per month. They require cloud infrastructure, user provisioning, and IT support for features most small operations will never configure, let alone use.

A local relational database sits between these two extremes. Items link to locations. Stock movements link to items. Every change carries a reason and a date. The data has structure, the storage is local, and there are no server fees.

The shape of an inventory database

A useful inventory database needs three tables, each with a different job.

The items table holds current state: SKU, name, category (Equipment, Consumable, Raw Material, or Finished Good), current quantity, unit of measure, a reorder threshold, cost price, retail price, a link to a storage location, and a notes field for specs or supplier info. One row per distinct item you stock.

The locations table holds where things go. Each location has a name ("Shelf A3", "Van 2", "Main Warehouse"), a building, and a description. Items link to locations, so you can filter by storage area or list everything in a specific van before it leaves for a job site.

The stock movements table is the audit trail. Each record links to an item and stores the quantity change (+10 received, -3 sold), a reason (Received, Sold, Damaged, Audit, or Transferred), the date, and who logged it. The items table holds the current count. The movements table records how it changed.

Three tables is the minimum for relational integrity. Without a separate movements table, you are back to overwriting cells in a spreadsheet with no way to trace how the count changed. Without a locations table, multi-site tracking collapses into a free-text field that nobody fills in consistently.

In Dosirak, these tables are defined in TOML files inside a project folder. The records live in SQLite. You can open the schema in any text editor and query the data with standard SQL tools.

What an agent does with inventory data

A clean schema with typed fields and table links is as readable by an AI agent as it is by a person looking at the TOML. With a structured inventory database, certain tasks become straightforward to automate.

An agent can query the database directly: "What items are below their reorder level?" It reads the schema through the embedded MCP server, runs the query against your local SQLite database, and returns the results. No API keys, no rate limits, no cloud round-trip.

Receiving stock is where it gets practical. Feed a supplier packing slip (a PDF or pasted text) to Claude Desktop. The agent parses the item names and quantities, then writes stock movement records in Dosirak. Counts are the sort of thing worth gating, so if you have put an approval gate on that table the movements wait as todo cards and you approve or correct each one before it lands.

The database sits on your disk and Dosirak never uploads it. Be aware that a cloud agent is a different matter: whatever you grant it to read, including supplier pricing, goes to its provider along with the packing slip. Grant it the movement tables and keep your cost columns out of its reach, or run a local model. More on the protocol in the MCP database feature page.

Spreadsheets, warehouse software, and a local database

Where this approach falls short

• Multi-warehouse supply chains with automated reorder points tied to supplier APIs. That is a warehouse management system problem, and Dosirak is not a WMS.
• Pick-pack-ship workflows integrated with UPS, FedEx, or other shipping carriers. Dosirak does not connect to carrier APIs.
• Teams of 20+ warehouse staff who need simultaneous real-time access from handheld devices. Dosirak is a single-operator desktop app for macOS and Windows.

This approach is for the shop owner counting stock on one machine, the AV rental company tracking gear across a few vans, or the lab manager who needs to know what is on which shelf.

Questions