Databases with no server

This site has no server. The Portugal section is 19 JSON files in a git repository, 1.3 MB in all, each with its hash in a manifest. Two real database engines run over exactly those files in your browser, compiled to WebAssembly: SQLite, and Oxigraph speaking SPARQL 1.1. Nothing is uploaded, nothing is queried remotely, and when the tab closes the database is gone. The files are the database. The engines are readers.

Two consoles over one set of files

The file system is the database

Every fact on the Portugal section lives in one JSON file that owns it: the people in people.json, the frozen pages in sources.json, the sessions in sessions.json. The build derives the other shapes a reader might want — the graph in graph.json, the same graph as RDF in triples.nt, the manifest with every hash — and nothing is derived twice. There is no import step, no schema migration and no connection string: the SQL console reads a loader spec, tables.json, that says which file and which field each column comes from, so a reader who doubts a cell can open the file it came from.

Three things follow, and they are the argument for doing it this way rather than a cheaper way of doing the usual thing:

• A query is reproducible against a commit. The files are versioned by git; a result carries the site version it ran against, and this page's examples record the row count they returned at build. A database that answers differently tomorrow with no commit in between is a database that has been edited.
• A check is a query. The Portugal build runs fifteen gates in Python — no verb its own inverse, every node naming a registered source, nobody in the graph who is not on the published list. Each is expressible as a query here, and the SPARQL console runs one of them as an ASK. When the rule and the check are the same sentence, the rule cannot drift from what is enforced.
• The reader pays nothing and trusts nothing. No account, no key, no request to a server that could log the question. The engine is 4.6 MB of vendored code, fetched once and cached; the data is the same files the page is built from. An agent gets the same: both consoles publish window.__tools after a tool:ready event, the convention graphs.sgit.ai's universe reader set.

What this is not

It is not a graph database, and graphs.sgit.ai's position is inherited on purpose: “not a graph database pitch — the claim is that one grammar is the interface at every boundary, not that things are stored in a graph.” The JSON stays the source of truth. The SPARQL store is built from it on load and thrown away on close; nothing is ever written back. Its shipped page lists “browser SPARQL/Cypher, RDF in code” under what that site does not have; this page is where the estate now has it, as a reader over files rather than a store of record.

It is not a server in disguise. The whole dataset is downloaded, which is fine at 1.3 MB and would not be at a gigabyte; that is the honest scaling limit of the pattern, and the sgit.ai guidance already names the answer — manifests at build time, files on click. And it is not a write path: corrections go through the files, the build and a version, which is the point.

What is vendored, and its cost

Both are vendored under assets/vendor/ and attributed in LICENSES.md, for the reason the rest of the site's third-party code is: an evidence chain should not end in a resource that can move. Cypher is shown beside each SPARQL query and not executed. Kùzu compiles to WebAssembly and would run it here; its package is 73 MB unpacked, which is the wrong price for a demonstration, and the choice is recorded rather than hidden.

The files each console loads

From manifest.json, which the file explorer renders and the Portugal gate re-verifies on every build.