Deprecating and removing Web SQL

The Web SQL Database API, which allows you to store data in a
structured manner on the user’s computer (internally based on the SQLite database engine), was
introduced in April 2009 and
abandoned in November 2010. While it
was implemented in WebKit (which powers Safari and early versions of Chrome) and remained active in
the Blink engine (that powers Chrome after the switch from WebKit), Gecko (which powers Firefox)
never implemented this feature and
WebKit removed it in 2019.

The World Wide Web Consortium (W3C)
encourages
those needing web databases to adopt
Web Storage API technologies like
localStorage and
sessionStorage, or
IndexedDB. These
technologies show their strengths when it comes to key/value stores and structured data, but
acknowledgely also have weaknesses like the lack of a strong query language. People want SQL on the
web for a reason.

# Web SQL deprecation steps

• Web SQL was deprecated and removed for third-party contexts in
  Chromium 97.
• Web SQL access in insecure contexts is deprecated as of
  Chromium 105 at which time a warning message will be shown in the Chrome DevTools Issue
  panel.

• Web SQL access in insecure contexts will be completely removed in a later
  milestone.
• The final step will be to remove Web SQL completely in all contexts, but
  no date has been set for this step yet.

# Where to go from here

As pointed out in the introduction,
Web Storage API technologies like
localStorage and
sessionStorage, or the
IndexedDB standard are
good alternatives in many, but by far not all cases.

We’re therefore working with the SQLite community on a replacement for Web SQL based on SQLite
implemented in WebAssembly (Wasm), which will be released in the near future. For developers looking
for a drop-in replacement, we’re investigating if a shim script can be provided. The article will be
updated once the replacement is ready.

# Rationale for leaving storage to web developers

With the advent of Wasm, SQL or NoSQL solutions can come to the web. One example is
DuckDB-Wasm, another is
absurd-sql. Based on these creations, we feel that the
developer community can iterate on and create new storage solutions faster and better than browser
vendors.

We’re not planning to just remove Web SQL. In fact, we’re planning to replace it with something that
will be maintained by the open-source community, served as a package that can be updated at
will—without the burden of introducing fixes and new features directly into browsers. Our objective
really is to let developers bring their own database to the web.

What’s more, we’re hoping that this example will help a new ecosystem of open-source databases to
flourish! The release of
file system access handles
finally provides the new primitive on which custom storage solutions can be built.

# Reasons for deprecating Web SQL

# Sustainability and security concerns

The Web SQL specification cannot be implemented sustainably, which limits innovation and new
functionality. The last version of the standard literally
states «User agents must implement the SQL dialect
supported by Sqlite 3.6.19». SQLite was not initially designed to run malicious SQL statements, yet
implementing Web SQL means browsers have to do exactly this. The need to keep up with security and
stability fixes dictates updating SQLite in Chromium. This comes in direct conflict with Web SQL’s
requirement of behaving exactly as SQLite 3.6.19.

# API shape

Web SQL also is an API that shows its age. Being a child of the late 2000s, it’s a great example of
«callback hell», as the code sample
(courtesy of Nolan Lawson) below
impressively demonstrates. As you can see, the SQL statements (using the
SQLite SQL dialect) are passed as strings to the database
methods.

openDatabase(
// Name
'mydatabase',
// Version
1,
// Display name
'mydatabase',
// Estimated size
5000000,
// Creation callback
function (db) {
    db.transaction(
// Transaction callback
function (tx) {
// Execute SQL statement
        tx.executeSql(
// SQL statement
'create table rainstorms (mood text, severity int)',
// Arguments
,
// Success callback
function () {
// Execute SQL statement
            tx.executeSql(
// SQL statement
'insert into rainstorms values (?, ?)',
// Arguments
,
// Success callback
function () {
// Execute SQL statement
                tx.executeSql(
// SQL statement
'select * from rainstorms where mood = ?',
// Arguments
,
// Success callback
function (tx, res) {
// Do something with the result
var row = res.rows.item(0);
                    console.log('rainstorm severity: ' + row.severity + ',  my mood: ' + row.mood);
},
);
},
);
},
);
},
// Error callback
function (err) {
        console.log('Transaction failed!: ' + err);
},
// Success callback);
function () {
        console.log('Transaction succeeded!');
},
);
},
);

If you were to run this code and
inspect the created table with Chrome DevTools, this is the
result:

# Lack of implementer support

Apart from the arcane API shape (at least from today’s point of view), Mozilla had many
concerns
about Web SQL being built upon SQLite:

«We don’t think is the right basis for an API exposed to general web content, not least of
all because there isn’t a credible, widely accepted standard that subsets SQL in a useful way.
Additionally, we don’t want changes to SQLite to affect the web later, and don’t think harnessing
major browser releases (and a web standard) to SQLite is prudent.»

You can read about Mozilla’s concerns in
former Mozillan Vladimir Vukićević’s blog post.
For some more history, check out the
W3C Web Applications Working Group minutes
(and, if you really want to go into the details, read the
IRC logs) and the
mailing list archives).
Additionally,
Nolan Lawson’s blog post
provides a good overview of what happened.

# Feedback

If you have any concerns about the deprecation steps communicated in this post, please let us know
on the blink-dev mailing list. Membership in
this group is open to anyone, and anyone is allowed to post.

# Related links

• All deprecations and removals in Chromium
• ChromeStatus entry:
  Deprecate and remove WebSQL in third-party contexts
• ChromeStatus entry:
  Deprecate and remove WebSQL in non-secure contexts
• Intent to Deprecate and Remove:
  WebSQL in third-party contexts
• Intent to Deprecate and Remove:
  WebSQL in non-secure contexts
• Chromium issue:
  Deprecate and remove WebSQL in third-party contexts
• Chromium issue:
  Deprecate and remove WebSQL in insecure contexts
• Chromium issue:
  Deprecate and remove WebSQL (Window#openDatabase)

# Acknowledgements

This article was reviewed by Joe Medley and
Ben Morss, and Joshua Bell. Hero
image by Jan Antonin Kolar on
Unsplash.