Deprecating and removing Web SQL

Thomas Steiner

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 remained active in the Blink engine (which powers Chrome), 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 acknowledgedly also have weaknesses like the lack of a strong query language. People want SQL on the web for a reason.

Web SQL deprecation and removal steps

[ Done.] Web SQL was deprecated and removed for third-party contexts in Chromium 97 ( January 4, 2022).
[ Done.] Web SQL access in insecure contexts was deprecated as of Chromium 105 ( January 4, 2022) at which time a warning message was shown in the Chrome DevTools Issue panel.

Chrome DevTools Issues panel with a warning that reads Web SQL in non-secure contexts is deprecated.

[ Done.] Web SQL access in insecure contexts is no longer available as of Chromium 110 ( January 4, 2022). An enterprise policy to keep using the feature is available from Chromium 110 ( January 4, 2022) to Chromium 123 ( January 4, 2022).
[ Done.] Web SQL access in all contexts is deprecated as of Chromium 115 ( January 4, 2022) and a warning message is shown in the Chrome DevTools Issue panel.
[ Done.] A deprecation trial to keep using Web SQL was available from Chromium 117 ( January 4, 2022) to Chromium 123 ( January 4, 2022). To learn more about deprecation trials, see Get started with origin trials.
[ Done.] Web SQL access in all contexts is no longer available from Chromium 119.

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.

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 replaced 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 features. 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 following code sample (courtesy of Nolan Lawson) demonstrates. As you can see, the SQL statements (using the SQLite SQL dialect) are passed as strings to 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
              ['somber', 6],
              // Success callback
              function () {
                // Execute SQL statement
                tx.executeSql(
                  // SQL statement
                  'select * from rainstorms where mood = ?',
                  // Arguments
                  ['somber'],
                  // 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:

Inspecting the Web SQL section in Chrome DevTools shows a database called mydatabase with a table called rainstorms with the columns mood (textual) and severity (integer) that has one entry with a mood of somber and a severity of six.

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 [SQLite] 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, let us know on the blink-dev mailing list. Membership in this group is open to anyone, and anyone is allowed to post.

Acknowledgements

This article was reviewed by Joe Medley and Ben Morss, and Joshua Bell.