本文建议使用SQLite进行测试，即使您在开发和生产中使用另一个RDBMS（我使用PostgreSQL）。我在一个测试用例中尝试了SQLite，它确实运行得更快（大约快18.8倍，0.5s vs 9.4s！）
在哪些情况下，使用SQLite会导致与使用PostgreSQL不同的测试结果
只有当我测试一段包含原始SQL查询的代码时？
任何时候，查询生成器都可能生成在不同平台上表现不同的查询，尽管查询生成器的平台抽象做出了努力。正则表达式、排序规则和排序的差异，聚合和分组的严格程度不同，使用全文搜索或其他扩展功能，使用除最简单的函数和运算符之外的任何函数和运算符，等等
此外，正如您所指出的，任何时候运行原始SQL。
在迭代开发期间在SQLite上运行测试是适度合理的，但在投入生产之前，您确实需要在要部署的同一个数据库上运行测试。否则，您将被某些查询所困扰，因为不同的引擎具有不同的能力，可以通过联接和GROUP BY来证明传递性相等，或者对查询的允许性不同，因此查询将在一个引擎上工作，然后在另一个上失败。
在实时推动更改之前，您还应该在一个合理的数据集上对PostgreSQL进行测试，以发现明显的性能退化，这将是生产中的一个问题。在SQLite上这样做没有什么意义，因为在SQLite中，通常完全不同的查询会很快或很慢。
我很惊讶你看到你报告的那种速度差。我想了解为什么测试在PostgreSQL上运行得如此慢，以及你能做些什么，因为在生产中，它显然不会有同样的性能差异。我在优化PostgreSQL以进行快速测试中写了一些关于这方面的内容。
在大多数情况下，性能特征会非常不同。通常速度更快。它通常适合测试，因为SQLite引擎不需要考虑多个客户端访问。SQLite一次只允许一个线程访问它。与其他RDBMS相比，这大大减少了很多开销和复杂性。
就原始查询而言，与Postgres或其他RDBMS相比，SQLite将有很多不支持的功能。尽可能远离原始查询，以保持代码的可移植性。当您需要为生产优化特定的查询时，情况会例外。在这些情况下，您可以在settings.py中保留一个设置，以检查您是否处于生产状态，并运行通用filters而不是原始查询。但是，有许多类型的通用原始查询不需要这种检查。
此外，SQLite数据库只是一个文件，这使得拆卸和重新开始测试变得非常简单。