数据库存储类型直接影响基准测试结果，因为它影响了数据的存储、访问和处理方式。 基于行的存储（例如，MySQL，PostgreSQL）将整个行存储在一起，使其可以高效地处理读取或写入整个记录的事务性工作负载。 基于列的存储（例如，Cassandra，Redshift）按列对数据进行分组，从而优化了聚合特定字段的分析查询。 内存数据库（例如，Redis，MemSQL）将数据存储在 RAM 中，从而减少了高速运行的磁盘 I/O 延迟。 测量读/写吞吐量、查询延迟或并发性的基准测试会根据这些存储模型而有很大差异。 例如，像 TPC-C 这样的事务基准测试有利于基于行的系统，而像 TPC-H 这样的分析基准测试在使用基于列的存储时性能更好。
具体用例突出了这些差异。 考虑一个测试批量数据插入的基准测试：由于行级锁定，基于行的数据库可能难以处理高写入量，而基于列的系统可以通过压缩列更有效地处理批量写入。 同样，在低延迟读取基准测试中，内存数据库的性能将优于基于磁盘的系统，但如果在发生电源故障时，它可能会在持久性测试中失败。 同一数据库中的存储引擎（例如，MySQL 中的 InnoDB 与 MyISAM）也显示出差异。 例如，在多线程基准测试中，与 MyISAM 的表级锁定相比，InnoDB 的 ACID 合规性和行级锁定会产生不同的并发结果。 这些示例说明了为什么基准测试必须与存储类型的优势保持一致。
权衡和配置选择进一步复杂了基准测试比较。 基于列的存储压缩减少了磁盘使用量，但增加了查询期间的 CPU 负载。 除非与快照或复制结合使用，否则内存系统会牺牲持久性来换取速度。 硬件依赖性也很重要：SSD 减轻了基于磁盘的系统的一些缺点，从而缩小了性能差距。 基准测试应考虑实际场景，例如混合的读取/写入工作负载或索引繁重的操作，在这些操作中，存储类型优化（例如，索引策略）起着至关重要的作用。 最终，没有一种存储类型可以主导所有基准测试——开发人员在解释结果时必须优先考虑用例需求（速度，可伸缩性，一致性）。