不同的数据库以不同的方式管理并发性，但在SQLite中，使用的方法是全局数据库级锁。一次只能有一个线程或进程对SQLite数据库进行更改；所有其他并发进程将被强制等待，直到当前运行的进程完成。
随着用户数量的增长；SQLite的简单锁定策略将导致日益激烈的锁定争用，您将需要将数据迁移到另一个数据库，如MySQL(它可以进行行级锁定，至少使用InnoDB引擎)或PostgreSQL(使用多版本并发控制)。如果您预计会有大量的用户(比方说，在一天中的大部分时间里，每秒有超过1个请求)，那么您应该从SQLite迁移出来；而且越早这样做，就越容易。

SQLite与BaseHTTPServer或任何基本的东西都不一样。这是一个功能齐全的“嵌入式”数据库。速度也很快。它的SQL语言可能没有最多的花哨，但它足够灵活。我还没有遇到过在我参与的项目中需要它做不到的事情(老实说，这不是典型的Web应用程序)。
任何声称SQLite对生产有好处或坏处而不讨论实际设计的人是不会告诉你太多的。SQLite的运行速度相当快。在某些情况下，它的速度真的比Postgres快了几个数量级，后者是Djangavis的首选选择。正如有人指出的那样，它还支持大量并发。这是一个你的应用程序是否被归入“某些案例”的问题。
现在，有一个重要的因素必须考虑在内。SQLite是一个进程内数据库。这真的很重要。如果你使用的是像GEvent这样的东西，你可能会遇到应用程序崩溃的边缘情况。例如，试图执行一个事务，而您在该事务中间有一个上下文切换，则可能会以可怕的方式中断事务。换句话说，“并发性”实际上取决于你的应用程序，因为SQLite是你的应用程序的“一部分”。
然而，在伸缩性方面，您不能使用SQLite做的事情是，您不能像使用其他数据库引擎那样创建SQLite服务器集群，因为它正在进行中。你的应用程序可能需要也可能不需要在可伸缩性方面付出如此大的努力，但我猜绝大多数应用程序无论如何都不需要(胡乱猜测)。
另一方面，进程中意味着向其添加自定义函数和聚合非常简单。我不确定Django的ORM是否会使这一点变得更加困难，但您可以利用这些特性提出非常好的设计。

数据库理论中的这个问题称为并发性，根据常见问题解答，SQLite在Windows版本>Win98和其他地方确实支持并发性：
Http://www.sqlite.org/faq.html#q5
据我们所知，没有其他嵌入式SQL数据库引擎像SQLite那样支持并发性。SQLite允许多个进程一次打开数据库文件，并允许多个进程一次读取数据库。当任何进程想要写入时，它必须在更新期间锁定整个数据库文件。但这通常只需要几毫秒的时间。其他流程只是等待作者完成，然后继续他们的业务。其他嵌入式SQL数据库引擎通常只允许单个进程一次连接到数据库。
基本上，不要担心并发性，任何称职的数据库都会处理得很好。有关SQLite3如何管理这一点的更多信息，请参见here。作为开发人员而不是数据库设计人员，您不必关心它，除非您对其内部工作原理感兴趣。

只有在某些特定情况下，SQLite才能在生产中有效工作。安装并运行MySQL或PostgreSQL非常容易，即使在Windows上也是如此，并且拥有一个在大多数情况下都能工作的数据库。
真正的问题是SQLite3在Django中没有线程，所以在您的服务器上一次只能有一个页面查看，请参阅此错误https://code.djangoproject.com/ticket/12118已修复
即使在开发中，我也不使用SQLite3。
编辑：我在这里一直被否决，但Django文档本身建议在我撰写此答案时不要在生产中使用SQLite3。该文档仍包含以下警告：
对于主要为只读或需要较小安装空间的应用程序，SQLite提供了一种极好的开发替代方案。
如果您没有较小的内存占用/只读Django示例，请不要使用SQLite3。请随意继续否决这一答案。

在生产中使用Django和Sqlite作为数据库并不是不可能的，这主要取决于您的网站/Webapp流量和您访问数据库的力度(以及您对其执行的操作类型，即读/写/等)。事实上，临近2019年底，我已经在几个日交互低于5k的低流量应用中使用了它(这些比你想象的更常见)。
简单地说，就目前的技术状态而言，Sqlite-3目前支持无限并发读取(或只要您的机器/工作人员能够处理)，但在任何时间点只有一个单个*进程可以写入它。请记住，设计良好的对数据库的查询/操作只会持续几毫秒！
来自于使用SQLite作为简单非例程(非例程，我的意思是典型的用户不会全年每天使用此应用程序)生产Web应用程序的海外工作匹配应用程序的经验，该应用程序处理约5000名注册学生(统计数据显示，在旺季，涉及访问数据库的请求一直低于2k-40%写入60%读取)，我从未遇到过任何超时/性能问题。
这真的可以归结为对开发和URS(客户端规范)持务实态度。如果它成为下一个独角兽，人们总是可以将SQLITE迁移到另一个RDBMS。例如，请参阅David d C e Freitas在Quick easy way to migrate SQLite3 to MySQL?中对迁移的看法
此外，SQLITE网站在其后端使用SQLite数据库。见下文..。
当然，SQLite网站(https://www.sqlite.org/)使用SQLite本身，在撰写本文时(2015)，它每天处理大约400K到500K的HTTP请求，其中大约15%-20%是访问数据库的动态页面。动态内容每个网页使用大约200条SQL语句。此设置在与23个其他服务器共享一台物理服务器的单个VM上运行，但在大部分时间内仍将平均负载保持在0.1以下。
请记住，上述引用当然主要是指读取操作，因此这些值可能不适用于写入繁重的站点。
如果您注意到这些数字，那么我在上面使用SQLite作为db构建的求职匹配应用程序上给出的示例非常繁重……平均而言，40%是短暂的写入操作(例如，表单提交等)，但请记住，在旺季，我访问数据库的数据量每天只有2K。
不过，如果您意识到您的sqlite.db导致了大量的超时和糟糕的用户体验(408！在表单提交时...)，特别是Django抛出OperationalError：数据库已锁定错误。**(然后他们必须再次键入整个内容)...当您准备迁移数据库时，您始终可以根据Django文档增加settings.py中的超时时间作为临时解决方案。

'OPTIONS': {
# ...
'timeout': 20,
# ...
}

同样，这一切都归结为务实的开发和面对的现实，即该网站可能不会像预期的那样吸引那么多的活动，而且从一开始就容易过度设计。
很多时候，选择简单的解决方案可以加快上市时间，本质上是快速试水，当然，也要做好准备，如果食人鱼真的成群结队涌入，然后是时候升级到另一个RDBMS了。
有了Django的ORM，在大多数情况下，在迁移到其他受支持的SQL数据库的过程中，您不需要触及Models.py。是非常MindFull尽管该Sqlite不支持一些更高级的功能，甚至不支持它的表兄弟MySQL和Postgres所支持的字段。

迟到了，但截至2018年年中，这个问题仍然是相关的。
博客网站的“客户端”是一个与“数据库客户端”不同的术语。SQLite文档将客户端称为打开数据库文件的进程。这样的进程，比如Django应用，可能会同时处理多个Web应用客户端(“用户”)，但从SQLiite的Angular 来看，它仍然只是一个客户端。
选择SQLite而不是合适的RDBMS的重要考虑因素是，您的体系结构是否由连接到数据库的多个软件组件组成。在这种情况下，使用SQLite可能是一个主要的性能瓶颈，因为每个应用程序都需要访问相同的数据库文件，可能是通过网络。
如果不是多个应用程序(数据库客户端)，在99%的情况下，SQLite是一个很好的生产选择。剩下的1%是使用特定数据库功能的应用程序，负载巨大的应用程序等。
了解您的架构。

这个问题的答案取决于您要在生产中部署的应用程序：
根据how to use from the SQLite website的说法，SQLite在生产中作为大多数低到中等流量的网站(也就是说大多数网站)的数据库引擎工作得很好。
他们认为，SQLite能够处理的网络流量取决于你对网站数据库的使用程度。众所周知，任何每天点击量低于10万次的网站都应该可以很好地使用SQLite。然而，这个10万点击量/天的数字是一个保守的估计，而不是一个严格的上限。
总之，对于用户和数据库使用量较少的应用程序来说，SQLite可能是一个很好的选择。因此，对于与数据库交互较少或中等的网站，请使用SQLite，对于与数据库交互较高的网站，请使用MySQL或PostgreSQL。
参考文献：sqlite.org