A 66MB SQLite file is the most interesting part of this project. Not the AI-assisted build story, not the GitHub Actions trick, and not even the MCP adjacency. A local, queryable copy of MDN browser compatibility data is the bit engineers can actually use.
This is a short project note from Simon Willison, so I would not overstate it. But I do think the direction is right: take a useful public dataset, put it in a boring format, publish it somewhere easy to fetch, and let people build on top of it.
What is browser-compat-db?
The project converts Mozilla's mdn/browser-compat-data repository into a SQLite database. The generated database is about 66MB, and it is published from a regular GitHub repository branch so it can be downloaded with open CORS headers. That matters because it means the data is not just downloadable; it is also easy to consume directly from browser-based tools.
The practical example in the source is Datasette Lite, which can open the hosted database remotely. That is a lot more useful than dumping JSON into a repo and calling it done.
The other useful detail is operational, not architectural: GitHub releases did not fit because of the CORS behavior, so the workflow builds the database and force-pushes it to a db orphan branch instead. That is a pragmatic workaround, and exactly the kind of detail that decides whether a dataset is actually reusable.
Why this is more useful than it looks
A lot of MCP discussion is still too demo-shaped. People are impressed that a model can call a tool, but the more important question is whether the underlying data is portable, inspectable, and cheap to move around.
This project gets that part right. SQLite is boring in the best way:
- easy to mirror
- easy to query
- easy to version around a build pipeline
- easy to use from local tools, scripts, and browser-based explorers
That has second-order effects. Once compatibility data is a plain database file, it becomes much easier to feed into internal developer tooling, validation jobs, documentation systems, or a custom MCP server development setup without forcing every consumer through a bespoke API.
In practice, that is also healthier from a governance standpoint. An internal tool can pin a known copy, review changes, and decide when to refresh. That is often better than depending on a live endpoint that can change behavior silently.
My verdict: the format choice is the real win
I think this is a good pattern, and better than many "AI data access" stories because it starts with the data product itself. If the source material is public and structured, shipping a database file is often the right answer.
The limitation is obvious too: this is not a managed service. You still need to know what schema you are querying, how often it refreshes, and how you want to consume updates. For teams that want policy, auditability, or controlled downstream use, you still need your own guardrails around it, the same way you would for any AI workflow automation component or internal Microsoft Copilot and AI agents integration.
I also would not miss the strategic angle: once engineers get used to portable SQLite artifacts with open hosting, some "API product" pricing starts to look weak. If a public dataset can be shipped as a 66MB file, then metered wrappers around it need to justify themselves with something real, not just convenience.
The practical takeaway is simple: if you are building MCP tools or browser-facing developer utilities, this is a pattern worth copying. Publish the data in a format people can inspect and move. The fancy interface can come later.
