我正在与另一位开发人员一起建立一个项目，这位开发人员经验丰富，能力出众，其技能和能力毋庸置疑。最近，我给他发了一个我所做的一些工作的演示，他似乎有点惊讶于我选择了火鸟数据库。对话是这样的：
他：你为什么选火鸟？SQLite会更快。
我：SQLite只是嵌入的，它的伸缩性不好。此外，它还缺少许多功能，包括对存储过程的支持。
他：Firebird也有可伸缩性问题，当你的数据库大小超过可用的RAM时。
我：你是什么意思？
他（直接引用他的电子邮件）：速度大幅放缓。显然，当索引+数据不适合RAM（物理RAM，而不是虚拟RAM）时，它会进入某种"慢模式"，我们已经能够通过增加FireBird-conf的内存使用值来在一定程度上缓解这种情况，但是，如果由于某种原因无法获取内存，则存在突然"内存不足"故障的风险（与MSSQL或MySQL f.i.相反，FireBird在启动时不保留物理RAM，只是逐步保留）。此外，在8GB以上的地方，即使在24GB的机器上，速度减慢似乎也会保持不变。因此，我们逐步将这些迁移到Oracle/MSSQL。
正如我所说，这是一个非常聪明、有能力的开发人员。但另一方面，我们有火鸟网站的说法，即人们在生产中使用它来处理大小超过11 TB的数据库，如果他说的是真的，那么无论出于何种目的，这都是不切实际的。
所以我不得不想，这个问题真的存在于火鸟身上吗，还是他忽略了什么，也许是他不知道的一些配置选项？有人熟悉他所描述的问题吗？
正如我之前所评论的，另一位开发人员所描述的可能是由于Windows 64位上的Windows文件系统缓存与Firebird使用FILE_FLAG_RANDOM_ACCESS读取其数据库文件的事实之间的组合中出现的一个错误。由于某种原因，这将导致文件系统缓存无法从其缓存中释放页面，从而导致其增长可能超过可用物理内存（最终甚至可能超过可用虚拟内存），有关详细信息，请参阅本博客文章。此问题已在Firebird 2.1.5和2.5.2中通过CORE-3971修复。
firebirdsql.org上的案例研究列出了几十个、几百个或千兆字节数据库的几个例子，它们似乎没有性能问题。
一家提供火鸟恢复和性能优化服务的公司不久前对一个1TB的数据库进行了测试。该页面还列出了三个相对较大的Firebird数据库示例。
披露：我为火鸟开发了一个数据库驱动程序，所以我可能有点偏见；）