你打开手机点外卖，据库商家在后台看到订单，据库骑手位置实时更新——这一串动作背后，据库数据在服务器和浏览器之间来回跑。据库支撑这套流程的据库，就是据库web数据库。

它不是据库装在你电脑里的Access文件，也不是据库手机本地存的SQLite。web数据库的据库核心特征只有一个：通过网络协议（通常是HTTP）对外提供服务，客户端不需要安装任何驱动或中间件，据库拿浏览器或者一个HTTP请求就能读写数据。据库换句话说，据库数据库从“装在机器上的据库软件”变成了“挂在网络上的服务”。

早年的据库做法是PHP+MySQL。服务器上跑一个MySQL实例，据库PHP脚本通过本地socket连上去，把查询结果拼成HTML吐给浏览器。这套架构撑起了Web 1.0和2.0的大部分站点。问题在于，MySQL并不是为HTTP场景设计的。每个请求都要建立TCP连接、做身份验证、维护会话状态，连接池管理稍有不慎就爆掉。我见过一个日活不到五万的论坛，MySQL连接数经常冲到max_connections上限，运维半夜起来重启。

后来出现了专门面向web的数据库服务。Firebase Realtime Database算一个典型。它把数据存成JSON树，客户端SDK直接监听节点变化，数据一改，所有订阅的浏览器自动收到推送。开发者不用写后端API，前端直接读写数据库。方便是真方便，坑也是真坑——数据量一大，JSON树的扁平化查询能力极差，想按某个字段排序过滤，要么冗余存储，要么全量拉下来在客户端筛。

再往后，Supabase、PlanetScale这类产品把PostgreSQL和MySQL包装成HTTP API。你发一个POST请求，body里带SQL语句或者RESTful路径，服务端返回JSON。底层还是关系型数据库，但访问层彻底HTTP化了。PlanetScale甚至基于Vitess做了分片，对外暴露的还是一个MySQL兼容的HTTP端点。这种设计的好处是，前端开发者不用学新的查询语言，用fetch就能操作数据。

国内也有类似的东西。微信云开发里的数据库，就是一个典型的web数据库。小程序端调用wx.cloud.database()，拿到的collection对象可以直接.where().get()，底层走的是微信私有协议，但概念上和HTTP API一致。开发者不用管服务器运维，不用配连接字符串，权限规则在控制台点几下就生效。代价是绑定微信生态，想迁走？数据导出格式都跟标准SQL对不上。

选型的时候有个判断标准很实用：看你的查询模式。如果读写都是简单的键值对，或者按文档ID取整条记录，Firebase、Cloud Firestore这类文档型web数据库很顺手。如果涉及多表join、聚合、事务，PostgreSQL包装的HTTP服务更靠谱。最怕的是拿文档数据库硬做关系型查询，代码里嵌套循环拼数据，性能塌方只是时间问题。

一个具体的坑：某创业团队用Firestore做订单系统，初期一切正常。后来运营要查“上个月下单超过三次但客单价低于50的用户”，这种查询在SQL里一句group by加having就完事，在Firestore里要么全量导出到BigQuery跑，要么在客户端遍历所有订单文档。他们最后选了后者，小程序卡到用户以为断网了。

web数据库把后端开发的门槛拉低了一大截，但数据库该有的复杂性一点没少。索引、事务、一致性、查询优化，这些老问题换了个HTTP的壳继续存在。别被“无服务器”“实时同步”这些词晃花了眼，先想清楚数据怎么进、怎么出、怎么查。想不清楚，换什么数据库都白搭。