聊到嵌入式数据库，很多人第一反应就是 SQLite，这玩意儿确实厉害，轻量、稳定、到处都能用。但你有没有想过，在资源极其有限的环境里，比如只有几 KB 内存的微控制器，或者需要极速启动的物联网设备，SQLite 这种基于 SQL 的关系型数据库有时反而显得“太重”。它需要解析 SQL 语句、维护表结构，这些操作在寸土寸金的嵌入式场景下会消耗宝贵的 CPU 周期和内存空间。这时候，一个叫 EJDB 的数据库就进入了我的视线。它不是要取代 SQLite，而是在另一个维度上找到了自己的位置——一个基于 JSON 文档、用 C 语言编写的嵌入式数据库，主打“极简”和“高效”。
EJDB 这个名字是 Embedded JSON Database，听名字就能知道它的核心是什么。它把数据直接存成 JSON 文档，你不需要事先定义表结构，也不需要写复杂的 SQL 语句，直接往里扔 JSON 对象就行。这就像有个大箱子，不用先规划格子，直接把东西放进去，再贴个标签方便查找。对于很多非关系型的数据场景——比如设备配置、日志记录、用户会话——这种“无模式”的设计简直不要太爽。而且它底层使用 Tokyo Cabinet 或 WiredTiger 之类的存储引擎，查询性能在嵌入式领域相当出色。我在一块只有几兆内存的开发板上跑过 EJDB，插入和查询几千条文档，响应速度毫秒级，几乎没有卡顿。
你可能会问，这玩意儿到底能用在哪儿？我第一个想到的就是物联网设备。现在的智能灯泡、智能插座，甚至一些工业传感器，都开始需要本地存储数据，比如运行日志、用户偏好设置。如果每次都要连上云端才能读写，延迟高不说，万一断网设备就成“砖头”。EJDB 正好可以充当本地缓存，设备端直接读写 JSON 文档，等网络恢复后再同步到云端。还有嵌入式路由器、智能网关，需要管理大量连接信息和配置参数，用 EJDB 这种轻量级文档数据库，比关系型数据库省资源得多，而且方便扩展。你不需要停机改表结构，直接加个新字段的 JSON 文档就行。
再往深里说，EJDB 的设计哲学其实很对路。嵌入式开发最怕的就是“杀鸡用牛刀”，一个简单功能引入一个庞大的数据库库，结果固件体积翻倍、内存占用飙升。EJDB 的库文件本身只有几十 KB，加上它的 API 设计非常简洁，C 语言里直接调用函数就能完成打开、插入、查询、更新和删除操作。它甚至支持简单的查询语法，比如根据某个字段的值筛选文档，或用正则表达式匹配。这种“够用就好”的思路，在嵌入式世界里比什么都重要。你不需要学一套复杂的 ORM 框架，也不需要配置主从复制，只要会写 JSON，就能上手。
当然，EJDB 也有短板。它不支持 SQL，也不支持复杂的关联查询和事务隔离级别。如果需要跨文档的联合查询，或者金融级别的数据一致性，它就不是最佳选择。但问题是，嵌入式场景里有多少需要这种复杂查询的？大多数情况下，你只需要快速读取某个设备的配置信息，或记录传感器的历史数据。用 SQLite 去搞这些，就像开着法拉利去菜市场买菜——不是不行，只是有点浪费。EJDB 更像随身带的一把瑞士军刀，小巧、实用，能解决 80% 的日常问题，剩下的 20% 交给更专业的工具。
我身边有个做智能家居的朋友，他们之前一直用 SQLite 做本地存储，结果发现每次设备启动时，SQLite 初始化表结构要花几十毫秒，且随着数据量增加，查询越来越慢。后来换成 EJDB，启动速度提升了 3 倍，内存占用降了一半。更重要的是，数据是 JSON 格式后，他们可以轻松把数据导出成标准的 JSON 文件，方便云端分析和调试。这种“原生 JSON”的特性非常有吸引力，尤其是前后端通信、配置文件、日志格式几乎全是 JSON。用 EJDB，你省去了数据格式转换的麻烦，写入和读取直接就是 JSON 对象，开发效率提升明显。
我想说，选技术栈就像选朋友，合适比高大上更重要。EJDB 不是万能的，它甚至有点“小众”，但在自己擅长的领域里，确实做到了极致——极致的小、极致的快、极致的简单。如果你正在做嵌入式项目，或者需要本地缓存的小型应用，与其一上来就用 SQLite 或更重的数据库，不如花半小时试试 EJDB。它可能不会带来惊艳的发布会效果，但能让你写代码时少掉几根头发，让设备跑得更流畅。技术圈有时太热衷追逐“高级”和“热门”，反而忽略了“刚好够用”才是最好的设计。EJDB 正是这种哲学的代表，安静地待在角落，等着真正需要它的人。
