今天聊个老古董，叫 Interbase 数据库。说它老，因为 1985 年就诞生了，比互联网普及还早，但你要是以为它早被淘汰了，那就错了。我接触这玩意儿是十年前，一个做工业控制的老哥跟我吐槽，说他们公司系统用了二十年，核心数据库就是 Interbase，想换又不敢换，因为业务逻辑全嵌在存储过程里，迁移成本高得吓人。后来我才知道，这哥们不是个例——Interbase 在嵌入式领域、POS 机系统、甚至军工设备里，至今还活得挺好。它不像 Oracle 那样满大街广告，也不像 MySQL 那样开源社区热闹，但就像个隐士高手，深藏功与名。
说到 Interbase 的历史，那可真是一部狗血剧本。它的创始人是 Jim Starkey，这哥们当年在 DEC（数字设备公司）干活，搞出了个叫 GDML 的数据库语言，后来辞职创业，1985 年发布了 Interbase 的第一个版本。最戏剧性的是，1986 年他因为滑雪事故瘫痪，但仍坐在轮椅上把代码写完了。产品随后被 Borland 收购，成了 Delphi 和 C++ Builder 的标配数据库，火遍全球。但 2001 年 Borland 干了个骚操作：他们在 Interbase 6.0 的代码里留了个后门，用户只要连上数据库，就能用 “politically” 这个用户名和密码直接登录，权限是管理员级别。这事被黑客发现后闹大，Borland 被迫开源。于是你现在看到的 Firebird 数据库，就是当年从 Interbase 开源分支里长出来的“亲儿子”。
技术层面，Interbase 有个特别牛的特色叫“多版本并发控制”。现在听起来不稀奇，但 80 年代这概念绝对是黑科技。简单说，就是读写操作不互锁——你读数据时，别人可以同时写数据，互不干扰。这机制让它在嵌入式场景里特别吃香，比如收银机、ATM 机、医疗设备，这些场景需要的是“开机就能用，不用配专职 DBA”。我有个朋友在便利店连锁公司干过，他们全国两万家门店的 POS 系统，底层就是 Interbase。每台机器上只有几 MB 的数据库文件，断电也不会丢数据，重启后自动恢复。这种“皮实耐造”的特性，让它在工业界口碑极好，哪怕后来 MySQL 和 PostgreSQL 崛起，很多老系统还是死守着 Interbase 不放。
但 Interbase 也有明显的短板，最要命的是生态太封闭。虽然 2001 年开源了，但 Borland 一直没把它当主流产品推广，社区也半死不活。你看 MySQL 有 Oracle 背书，PostgreSQL 有全球志愿者贡献代码，Interbase 却像后妈养的孩子。有个数据挺扎心：2023 年 DB‑Engines 排名里，Interbase 排在第 50 名之外，而它衍生出的 Firebird 已经进到 30 多名。更尴尬的是，它的 SQL 语法与主流数据库差异较大，比如不支持公用表表达式，窗口函数也是后来才勉强加上的。这导致新开发者根本不想碰它，除非被老系统绑死的倒霉蛋。
不过话说回来，Interbase 在特定领域依然有不可替代的价值。比如嵌入式场景，它的安装包只有几 MB，内存占用不到 50 MB，而 MySQL、PostgreSQL 至少需要几百 MB。再比如对实时性要求极高的控制系统，Interbase 的恢复速度几乎是瞬时的，因为它的日志机制特别轻量。我认识一个做高铁信号系统的工程师，他们十年前用 Interbase 做数据采集，到现在都没出过大故障。这种“老而不死，反成经典”的特性，实际上反映了数据库选型的一个真相：很多时候，稳定比时髦重要一万倍。
从商业角度看，Interbase 的没落也给了很多启示。它输在母公司 Borland 的一通骚操作：先是不思进取，连个像样的图形化管理工具都不给；然后搞出后门事件，信誉扫地；开源又不彻底，把代码版权攥在手里，导致社区分裂出 Firebird。这跟当年微软的“拥抱‑扩展‑再消灭”策略如出一辙，只不过 Borland 没那个本事。反观 Firebird，因完全开源、社区活跃，现在反而活得比亲爹更滋润。所以你看，技术产品有时候跟人一样，出身好不如命硬，命硬不如有个好爹。
说个冷知识：Jim Starkey 在 2000 年又搞了个新数据库叫 NexusDB，专门针对嵌入式场景，但没掀起什么波澜。2015 年他退休后，Interbase 的维护工作交给了外包团队，更新频率从每年一次降到三四年一次。但有意思的是，2022 年 Interbase 2020 版发布时，居然还加入了 JSON 支持和云部署功能。这就像个八十岁的老头突然去学街舞——动作可能不标准，但至少证明他还活着。或许这就是 Interbase 的宿命：在角落里安静运行，偶尔被骂几句“老掉牙”，但只要还有一台 POS 机在用它，它就永远不会消失。
