In 2009, browsers quietly gained something remarkable: a real, embedded relational database, queryable with SQL, requiring zero installation and no back-end infrastructure. WebSQL was imperfect, politically contentious, and built on a foundation that made standards bodies uncomfortable. But it worked. And for a certain class of application — lightweight, data-driven, offline-capable, accessible to people who knew SQL but not JavaScript — it was genuinely transformative. Fifteen years later it is gone, deprecated in Chromium v125 in June 2024, with no standards-based equivalent to take its place. That absence deserves more scrutiny than it has received.
This is not simply a nostalgic lament for a deprecated API. It is a question about how the web standards process handles the gap between what is technically inconvenient and what is genuinely needed — and whether the browser developer community, in removing WebSQL, solved the problem or merely made it invisible.
What WebSQL Actually Was
WebSQL was a browser API, first appearing in WebKit-based browsers around 2009, that exposed a SQLite-backed relational database to web pages via JavaScript. You could create tables, run SELECT statements with joins, build views, index data, and query it at speeds that reflected the fact that the engine was running natively — not simulated on top of some other storage abstraction. For anyone who had spent time working with relational data, the capability felt intuitive in a way that the alternatives never quite matched.
The key advantages were not subtle. WebSQL could handle genuinely large datasets without performance degradation. It supported arbitrary relational joins across multiple tables. It could interpret end-user input as SQL directly, meaning that non-JavaScript programmers — analysts, researchers, data scientists — could interact with browser-side storage without writing code. It supported persistent views, not just tables. And it did all of this with zero installation, embedded directly in the browser.
- Zero installation — embedded natively in the browser
- Capable of handling large datasets at native speed
- Arbitrary relational joins across multiple tables
- End-user SQL input — no JavaScript programming required
- Persistent views, not just tables
- Genuinely fast — not SQL layered over another storage model
- Enabled truly server-less, back-end-free data processing
The Standards Impasse of 2010
The trouble began almost immediately. In November 2010, the W3C editor responsible for the WebSQL specification announced that work on the spec was being halted. The stated reason was that the specification referenced SQLite as its underlying implementation — meaning the standard was tied to a specific piece of software rather than describing an abstract interface. The concern was legitimate in principle: a web standard should not mandate a particular vendor’s product. If SQLite were to change significantly, or if a browser wished to use a different engine, the standard would provide no meaningful guidance.
But the practical consequence of this decision was never adequately addressed. The impasse did not produce a better standard. It produced no standard. For fifteen years, the browser community acknowledged that a browser-native relational database had value, declined to standardise it properly, and allowed the existing implementation to decay through successive removals of functionality — full-text search gone here, third-party context support gone there — until the technology was sufficiently hobbled that deprecating it entirely could be presented as a minor housekeeping exercise.
The impasse did not produce a better standard. It produced no standard at all — and the implementation was mangled in the interim.
A Fifteen-Year Managed Decline
What followed 2010 was not a clean deprecation. It was a slow process of attrition, in which WebSQL’s capabilities were progressively stripped away while the technology remained nominally available — creating genuine uncertainty for developers trying to build on it. The trajectory looked something like this:
- 2009WebSQL introduced in WebKit-based browsers. SQLite under the hood. Fast, capable, and immediately useful for data-driven web applications.
- 2010W3C halts standardisation work. The spec is frozen. No replacement is proposed. WebSQL enters a permanent state of standards limbo.
- 2010sFull-text search (FTS) capability removed from WebSQL in various browsers citing security concerns. Outer join support becomes inconsistent across implementations. Third-party context support removed. Each removal narrows the technology’s usefulness without addressing the underlying standards question.
- 2019–2023Chromium announces intent to deprecate. A deprecation trial begins in Chromium v119 (November 2023). The framing is largely technical — the spec is not maintained, the implementation is a security surface — with limited acknowledgement of what will be lost.
- June 2024WebSQL fully deprecated in Chromium v125. Mainstream browsers cease support. The fifteen-year experiment ends not with a replacement, but with a gap.
The SQLite WASM Non-Answer
The browser community’s proposed replacement is SQLite compiled to WebAssembly (WASM) — a port of the same underlying engine that powered WebSQL, now running as a WASM module that web pages can load and use. In certain respects, this is promising. SQLite WASM is actively maintained, reasonably capable, and not tied to a single browser’s implementation decisions.
But it misses the primary point entirely. SQLite WASM is not a web standard. It is a library that developers download and bundle, subject to the same version management, dependency, and distribution concerns as any other JavaScript dependency. There is no specification, no browser-native integration, no guarantee of consistent behaviour across environments. The problem the W3C identified in 2010 — that WebSQL lacked proper standardisation — has not been solved. It has been deferred.
To be fair, SQLite WASM with an OPFS data store is a capable solution and in many practical workloads it performs comparably to WebSQL. Where it can struggle is at the edges — complex joins across large datasets being the most notable case — where a natively embedded engine has a natural advantage over one running through a WASM layer. But performance is honestly a secondary concern. Even if SQLite WASM matched WebSQL in every benchmark, it would still not be a web standard, and that distinction matters.
The Ecosystem Has Changed; the Standards Have Not
The irony is that the web ecosystem in 2026 is substantially more demanding of browser-side relational data processing than it was in 2009. CORS-enabled open datasets are now ubiquitous. Civic data portals, government open data APIs, research data repositories — all expose large, structured, relational datasets that a browser-native SQL engine could query directly, without a back-end, without cloud infrastructure, without requiring the developer to be a JavaScript expert.
Not everyone who works with data is a JavaScript programmer. SQL is one of the most widely understood data query languages in the world, spanning database administrators, analysts, researchers, GIS professionals, and many others. A browser-native SQL engine lowers the barrier to building genuinely useful, data-driven applications to the point where a non-programmer can do it. That is a significant capability to lose, and “use SQLite WASM” is not an equivalent answer for someone who was relying on the browser to handle the infrastructure transparently.
IndexedDB — the other commonly cited alternative — is JavaScript-based and requires programmatic data extraction for anything resembling a relational join. It cannot interpret end-user SQL input. It is a key-value store with transactional semantics, not a relational engine, and presenting it as an equivalent replacement for WebSQL reflects a misunderstanding of what WebSQL was actually used for.
What Should Have Happened
The W3C’s 2010 objection — that WebSQL was too tightly coupled to a specific implementation — was a reasonable technical concern. But the appropriate response was to write a better specification, not to abandon the effort entirely. The SQL language itself is standardised (ISO/IEC 9075). A browser API specification could have defined the interface, the behaviour, and the required SQL dialect, while permitting browser vendors to choose their own underlying implementation. This is how most web standards work.
Instead, the community took the path of least institutional resistance: declare the problem too hard, freeze the spec, let the implementation decay, and eventually remove it. The developers who built applications on WebSQL — and the users who benefited from them — absorbed the cost of that decision quietly, over many years, one removed feature at a time.
The question now is whether the community is willing to revisit the underlying need. SQLite WASM is a workable stopgap for developers who are already comfortable with JavaScript dependencies. It does not address the elephant in the room: the absence of a standards-based, natively embedded relational database in the browser. That gap existed in 2010. It exists in 2026. And the web’s growing dependence on large, open, relational datasets makes it more consequential, not less, with every passing year.
WebSQL was not removed because the problem it solved had gone away. It was removed because the problem of standardising it properly was never solved — and allowing a non-standard implementation to persist indefinitely was eventually deemed more awkward than simply ending it. That is an understandable institutional decision. It is not a good outcome for the web.
The security concerns that drove successive removals of WebSQL functionality over the years were real. But those concerns were addressed by removing features rather than fixing them — which is how a useful technology gets mangled into an unrecognisable remnant of itself before being quietly put down. The browser community should be honest that what was deprecated in 2024 was not the WebSQL of 2009. It was what remained after fifteen years of attrition.
A standards-based, browser-native relational SQL engine remains a genuine need. The web ecosystem in 2026 — with its ubiquitous open datasets, its offline-first applications, its users who understand SQL but not JavaScript — would benefit from one at least as much as it would have in 2009. Whether that argument is finally heard is a question for the standards community. But the first step is being clear that the question was never actually answered. It was just set aside.