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 acknowledgedly also have weaknesses like the lack of a strong query language. People want SQL on the web for a reason.

Success

Our intention is to empower developers to create their own solutions for structured storage. We've worked with the SQLite team to create a SQLite implementation over WebAssembly. This solution is now ready and outperforms Web SQL in many cases.

# Web SQL deprecation and removal steps

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

• [📍 We are here.] Web SQL access in insecure contexts is no longer available as of Chromium 110 (February 6, 2023). An enterprise policy to keep using the feature is available from Chromium 110 (February 6, 2023) to Chromium 111 (March 6, 2023).
• [🔮 In the future.] 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.

# 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 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
              ['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:

# 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, 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)
• SQLite Wasm in the browser backed by the Origin Private File System

# Acknowledgements

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