先看看他们的共同之处：
共同特点
基于客户端的存储
实际上，“客户端时间存储”的意思是，数据传给了浏览器的存储 API，它将数据存在本地设备中的一块区域，该区域同样也是它存储其他用户特定信息如个人偏好、缓存的地方。除了存储数据，这些 API 可以用来检索数据，且在某些情况下还能执行搜索和批处理操作。
置于沙盒中的
所有这四个存储 API 都将数据绑到一个单独的“源”（origin）上。
空间限制（Quotas）
你能想象，如果任何网站都被允许往毫不知情的硬盘里填充以千兆字节计的数据，该有多混乱。因此，浏览器对存储容量施加了限制。若你的应用试图超出限制，浏览器通常会显示一个对话框，让用户确认增加。您可能以为浏览器对单个源（origin）可使用的所有存储都加以同一单独的限制，但多数存储机制都是单独加以限制的。若 Quota API 被采纳，这种情况可能会改变。但就现在来说，把浏览器当作一个二维矩阵，其维度分别是“源”（origin）和“存储”（storage）。abc.example可能会允许最多存 5MB 的 Web Storage， 25MB 的 Web SQL 数据库，但因用户拒绝访问被禁止使用 Indexed DataBase。 Quota API 将问题放到一起来看，让您查询还有多少可用空间，有多少空间正在使用。
有些情况下，用户也能先看到有多少存储将被使用，例如，当用户在 Chrome 应用商店中安装一个应用时，他们将被提示预先接受其权限，其中包括存储限制。（而该应用的）manifest 中的可能有个值是 “unlimited_storage” （无限制存储）。
数据库处理（Transactions）
两个 “数据库” 的存储格式支持数据处理。目的和通常的关系型数据库使用数据处理是一样的：保证数据库完整。数据库处理（Transactions）防止 “竞争条件”（race conditions） —— 这种情况是：当两个操作序列在同一时间被应用到数据库中， 导致操作结果都无法被预测，而数据库也处于可疑的准确性（dubious accuracy）状态。
同步和异步模式（Synchronous and Asynchronous Modes）
多数存储格式都支持同步和异步模式。同步模式是阻塞的，意味着下一行 js 代码执行之前，存储操作会被完整执行。异步模式会使得后面的 js 代码在数据库操作完成之前执行。存储操作会背景环境中执行，当操作完成的时候，应用会以回调函数被调用这种形式接收通知，这个函数须在调用的时候被指定。
应当尽量避免使用同步模式，它虽然看起来比较简单，但操作完成时它会阻塞页面渲染，在某些情况下甚至会冻结整个浏览器。你可能注意到网站乃至是应用出现这种情况，点击一个按钮，结果所有东西都用不了，当你还在想是不是崩溃了？结果一切又突然恢复正常了。
某些 API 没有异步模式，如 “localStorage”， 使用这些API时，应当仔细做好性能监测，并随时准备切换到一个异步API，如果它造成了问题。
API 概述及比较
Web Storage
Web Storage 是一个叫做 localStorage 的持久对象。可以使用 localStorage.foo = "bar" 保存值，之后可以使用 localStorage.foo 获取到 —— 甚至是浏览器关闭之后重新打开。还可以使用一个叫做 sessionStorage 的对象，工作方式一样，只是当窗口关闭之后会被清除掉。
Web Storage 是 NoSQL 键值对储存（NoSQL key-value store）的一种.
Web Storage 的优点
数年以来，被所有现代浏览器支持， iOS 和 Android 系统下也支持（IE 从 IE8 开始支持 ）。
简单的API签名。
同步 API，调用简单。
语义事件可保持其他标签和窗口同步。
Web Storage 的弱点
使用同步 API（这是得到最广泛支持的模式）存储大量的或者复杂的数据时性能差。
缺少索引导致检索大量的或复杂的数据时性能差。（搜索操作需要手动遍历所有项。）
存储或读取大量的或复杂的数据结构时性能差，因为需要手动序序列化成字符串或将字符串反序列化。主要的浏览器实现只支持字符串（尽管规范没这么说的）。
需要保证数据的持续性和完整性，因为数据是有效非结构化（effectively unstructured）的。
Web SQL