There's No Database Server Behind bomwerk. On Purpose.

A lot of security and compliance tools ask for more than you'd expect before you can run them. Stand up a Postgres instance. Open a port. Create a service account. Configure a connection string. And that's before the tool does anything useful for you.

None of that is unreasonable on its own. It's just a cost, and it's a cost that shows up before day one, on infrastructure that isn't the tool's job to own.

The constraint we're actually solving for

bomwerk is built to run on-prem, sometimes fully air-gapped. No telemetry leaves the machine unless you turn something on and point it somewhere yourself. That's not a marketing line, it's a structural choice: the whole trust story falls apart if the tool phones home or needs a network path to function.

Given that constraint, asking someone to also run a database server changes the deployment story completely. Now there's a second thing to patch, a second thing that can go down, a second thing security has to approve before it's allowed anywhere near a build server. For a tool that's supposed to make audits easier, that's a strange thing to hand someone.

What we chose instead

Local state, wherever bomwerk needs to keep any, lives in SQLite. One file. No server process, no listening port, no credentials to rotate. Copying it is a backup. Deleting it is a reset. It behaves identically on a developer's laptop, inside a CI runner with no network access, or on an air-gapped machine in a secure facility, because there's no difference between those environments as far as SQLite is concerned. It's just a file on disk.

That matters more than it sounds like it should for a tool whose entire pitch is "runs inside your infrastructure, doesn't ask anything of it."

This is the design a forthcoming piece of bomwerk leans on directly: a registry that tracks SBOMs per product and version over time, so you can answer "what did we ship in March versus June" without re-scanning anything. That's still ahead of us on the roadmap, not something you can run today. But when it lands, backing it up will look exactly this ordinary:

$ cp registry.db backups/registry-2026-08-27.db
$ sqlite3 backups/registry-2026-08-27.db ".tables"
components  products  scans  versions

No pg_dump, no connection string, no separate backup tooling. Just a file, copied like any other file.

Where this stops being the right call

SQLite isn't built for a lot of concurrent writers hammering the same database at once. That's a real limitation, and it's not one we're pretending away.

For a per-product registry watched by a single on-prem instance, that limitation doesn't bite. One process is writing to it. But if bomwerk ever needs to serve a shared setup where many teams are writing to the same store at the same time, a directory of SQLite files stops being the right architecture. That's exactly the door we left open on purpose: Postgres as a swap-in option for larger deployments is on the roadmap for a later Enterprise phase, not something we're bolting on after the fact under pressure. The decision to keep it optional, not required, was made early, specifically so smaller deployments never have to carry infrastructure they don't need.

Why this is worth a whole post

Nobody chooses a security tool because of its storage engine. But plenty of tools get quietly uninstalled, or never make it past a security review, because of exactly this kind of operational weight nobody budgeted for. A database server is one more thing that has to survive a change advisory board, one more thing that needs patching on its own schedule, one more line item in whatever audit asks "what runs in our environment and why."

A single file doesn't have any of those problems. It's not a clever trick. It's just choosing not to create a dependency the tool didn't actually need.

The parts of a tool nobody asks about at the demo are often the parts that decide whether it's still running in someone's infrastructure a year later.