首先，W3C已经弃用的是WebSQL而不是SQLite
IndexedDB -

• 它与许多类型的移动的操作系统不兼容，仅与某些类型的移动操作系统版本兼容
• 开发人员不能将SQL与IndexedDB一起使用。他们可以将SQL与SQLite和WebSQL一起使用
• 大多数开发人员都尽量避免使用IndexedDB

网络SQL-

• W3C已弃用它，这意味着不再维护或开发它
• 它需要另一个名为Polyfill的插件，以使移动的应用程序能够与流行的移动操作系统（如谷歌Android和苹果iOS）一起工作

SQLite数据库-

• 它获得了谷歌的奖项
• SQLite有自己的官方网站，IndexedDB和WebSQL没有
• 在Google上，SQLite返回430万个结果，WebSQL返回的结果略少于70万个，IndexedDB返回的结果为28.2万个。

如果您需要SQLite的快速教程，
使用Android和Phonegap存储SQLite数据库

我认为放弃IndexedDB是个坏主意，因为它可能是未来的格式，所以Safari可能会停止支持WebSQL。
似乎有各种JavaScript解决方案可以弥补这两者之间差距--保存在用户浏览器上可用的任何一个中：JavaScript Library to Bridge IndexedDB and WebSQL我认为这可能是您最好的解决方案。

是的，IndexedDB API很棒，所有浏览器都将在不久的将来支持。
我绝对推荐我自己的解决方案https://bitbucket.org/ytkyaw/ydn-db，它是IndexedDB的非常薄的 Package 器，对于Safari则可以回到Sqlite。

IndexedDB很可能是未来支持的数据库，最好使用IndexedDB而不是WebSQL。正如Raymond指出的，最好参考http://www.caniuse.com来了解桌面和移动的浏览器当前/未来的支持。
根据您的解决方案的当前需求，您可以使用许多可用的JavaScript库中的一个，它使用本地存储并提供查询接口。其中一个对我来说运行良好的库是Lawnchair。

如果您不想在IndexedDB或WebSQL之间进行选择，则可以使用Javascript库PouchDB。
我在Android Webview中使用它来存储离线数据，效果相当不错。如果没有可用的互联网连接，数据将存储在本地数据库（使用IndexedDB或WebSQL）上，当有可用的连接时，数据将与远程数据库（CouchDB数据库）同步。
PouchDB将依赖于IndexedDB，但如果不支持IndexedDB，则回退到WebSQL。也可以使用用于Cordova/PhoneGap的SQLite插件。

我想做一个小的编辑来更新这个问题，因为谷歌是直接向我们提出这个问题，如果你对websql，localStorage和indexedDB的主题进行研究。编辑被拒绝，所以我张贴作为答案。
正如其他人在回答中所说的那样，IndexedDB以前在支持和Web上的文档和规范内容方面有点欠缺。
但是IndexedDB对移动的的支持已经得到了很大的改进。它改进得如此之多，以至于唯一没有支持的浏览器是Opera Mini，but it has only 0,34% of market usage。
从2015年开始，我建议所有开发人员迁移到IndexedDB，因为WebSQL已经被弃用，IE和Firefox也不再支持它（单是这些就占了市场使用量的15%以上！）SQLite正在迅速流失空间给IndexedDB，后者现在有非常好的documentation sources、many、Some official as well！。一些IT公司甚至也在鼓励使用，例如IBM。
我打算使用它，到目前为止我还没有遇到任何问题。Safari已经增加了对它的支持，所有主要的浏览器也是如此。去吧！
编辑：个人附录：我试过IndexedDB。我是团队中的资深成员，IndexedDB语法对于小的存储问题来说太混乱和复杂了--我结束了使用localstorage来保存一些简单的JSON数据，并在需要时解析它。对我团队中的任何人来说都是更好的选择（当然，我也是！）

这可能晚了一点，但您可以查看：SequelSphere
它是一个100%的HTML5/JavaScript关系数据库，可以跨浏览器工作，并使用本地存储来保存它的数据。你也可以使用SQL来查询它。它是它自己的数据库引擎，不依赖于内置的（WebSQL）关系数据库。因此，它可以跨所有浏览器工作。
虽然它目前只支持localStorage，但它的想法是支持未来的所有标准。由于浏览器支持其他类型的持久性，SequelSphere将利用这一点。积极的一面是，您只需要使用标准SQL对SequelSphere进行编码，并让它处理持久性。
尽管如此，要知道，这是一个新产品的市场，所以这既有积极的和消极的。

正如其他人所指出的，自从这个问题被提出以来，webSQL已经被弃用，而IndexedDB实现现在存在于所有主要的浏览器供应商中。
因此，对于任何可能发现自己在这里面临同样决定的人，请选择IndexedDB。
这里的其他人也正确地暗示，不必在两种类型的数据库之间做出选择，可以简单地选择（或创建）一个库，该库利用客户机上可用的任何数据库。
如果你正在寻找这样一个库，可以看看BakedGoods。它建立了一个统一的接口，可以用来在所有本机和一些非本机客户端存储设备中进行存储操作。它还保持了每种存储设备为用户提供的灵活性和选项。
有了它，在支持的任何数据库类型中执行存储操作都是一个问题...
...为两种数据库类型指定适当的操作选项和等效配置：

//If the operation is a set(), and the referenced structures 
//don't exist, they will be created automatically.

var webSQLOptionsObj = {
    databaseName: "Example_DB",
    databaseDisplayName: "Example DB",
    databaseVersion: "",
    estimatedDatabaseSize: 1024 * 1024,
    tableData: {
        name: "Main",
        keyColumnName: "lastName",
        columnDefinitions: "(lastName TEXT PRIMARY KEY, firstName TEXT)"
    }, 
    tableIndexDataArray: [name: "First_Name_Index", columnNames: "(firstName)"]
};

var indexedDBOptionsObj = {
    databaseName: "Example_DB",
    databaseVersion: 1,
    objectStoreData: {
        name: "Main",
        keyPath: lastName,
        autoIncrement: false
    },
    objectStoreIndexDataArray: [
        {name: "First_Name_Index", keyPath: "firstName", unique: false, multiEntry: false}
    ],
};

var optionsObj = {
    conductDisjointly: false, 
    webSQL: webSQLOptionsObj, 
    indexedDB: indexedDBOptionsObj
};

...并执行操作：

bakedGoods.set({
    data: [
        {value: {lastName: "Obama", firstName: "Barack"}}, 
        {value: {lastName: "Biden", firstName: "Joe"}}
    ],
    storageTypes: ["indexedDB", "webSQL"],
    options: optionsObj,
    complete: function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
});

其简单的界面和无与伦比的存储设备支持，代价是缺少对一些存储设备特定配置的支持，例如不支持对多列主键的WebSQL表进行存储操作。
因此，如果你大量使用那些类型的功能，你可能想看看其他地方。
哦，为了完全透明，BakedGoods是由这个家伙维护的：）。