Compatibility Isn't a Chart. It's 260,715 Rows.

Browser support gets expensive when you're bouncing between a chart, your editor, and a bug report, trying to answer one question one screenshot at a time.

That is what Simon Willison's browser-compat-db repo is actually about. It is not another take on whether browser support is annoying. It takes MDN's browser compatibility data and turns it into a small SQLite database you can query.

In the 2026-06-24 snapshot, that database has 19,834 features and 260,715 support rows. The schema is split into tables like features, support, feature_tags, and browser_releases, and there is a Datasette Lite view for quick searching.

That changes the job. Instead of checking one API box at a time, you can ask better questions: which browser + release combinations are hiding risk, which experimental features keep showing up, and where are the prefixed leftovers?

Compatibility isn't a web chart. It's data you should interrogate with SQL.

MDN already describes browser-compat-data as machine-readable compatibility data, and tools like Can I Use, VS Code, WebStorm, Firefox, and TypeScript already consume it. So the interesting part here is not that a database exists. It is that compatibility stops being a thing you eyeball and starts being a thing you can query.

Boundary check: this is a public repo snapshot from 2026-06-24, not proof from testing every phone and laptop on earth. It also does not mean every team should build a database from scratch. It just means browser support gets more trustworthy when it stops living as vibes, screenshots, and tab overload.

A lot of people think they need better instincts. Most of the time, they need fewer tabs. Share this with the teammate who still debugs compatibility by feel. #FrontendDev #BrowserTesting #WebDevTips #DevWorkflow