我的Django项目将由一个包含数十万个条目的大型数据库支持，并且需要支持搜索(我可能最终会使用djangosearch或类似的项目。)

哪个数据库后端最适合我的项目？为什么？ 你能推荐任何好的资源进一步阅读吗？

无论它值多少，Django的创造者都推荐使用PostgreSQL。

If you're not tied to any legacy
system and have the freedom to choose
a database back-end, we recommend
PostgreSQL, which achives a fine
balance between cost, features, speed
and stability. (The Definitive Guide to Django, p. 15)

作为最近将项目从MySQL切换到Postgresql的人，我不后悔转换。

从Django的角度来看，主要区别在于Postgresql中更严格的约束检查，这是一件好事，而且手动架构更改(即迁移)也更加繁琐。

大概有6个左右的Django数据库迁移应用程序，至少有一个不支持Postgresql。我不认为这是一个缺点，因为你可以使用其他人之一或手动完成(这是我更喜欢的atm)。

MySQL可能更好地支持全文搜索。 MySQL内置全文搜索功能，从Django内部支持，但它没用(没有词干，短语搜索等)。我使用django-sphinx作为MySQL中全文搜索的更好选择。

使用Postgresql 8.3内置全文搜索(早期版本需要TSearch模块)。这是一篇很好的教学博客文章：使用PostgreSQL和tsearch2在Django中进行全文搜索

large database with several hundred
thousand entries,

这不是大型数据库，它非常小。

我选择PostgreSQL，因为它有更多的功能。最重要的是这种情况：在PostgreSQL中，您可以使用Python作为过程语言。

即使Postgresql看起来更好，我发现它与Django有一些性能问题：

Postgresql用于处理"长连接"(连接池，持久连接等)

MySQL用于处理"短连接"(连接，执行查询，断开连接，与许多打开的连接有一些性能问题)

问题是Django不支持连接池或持久连接，它必须在每次视图调用时连接/断开数据库。

它可以与Postgresql一起使用，但是连接到Postgresql比连接到MySQL数据库要花费更多(在Postgresql上，每个连接都有自己的进程，它比在MySQL中弹出一个新线程慢得多)。

然后，您将获得一些功能，如查询缓存，在某些情况下可能非常有用。 (但你失去了PostgreSQL的精湛文本搜索)

选择你更熟悉的人。 MySQL vs PostgreSQL是一场无休止的战争。它们都是出色的数据库引擎，两者都被主要站点使用。在实践中真的没关系。

所有的答案都会给桌子带来有趣的信息，但有些信息有点过时，所以这就是我的盐。

从1.7开始，迁移现在是Django的一个不可或缺的特征。因此，他们记录了Django开发人员可能希望事先知道的主要差异。

Backend Support

Migrations are supported on all backends that Django ships with, as
well as any third-party backends if they have programmed in support
for schema alteration (done via the SchemaEditor class).

However, some databases are more capable than others when it comes to
schema migrations; some of the caveats are covered below.

PostgreSQL

PostgreSQL is the most capable of all the databases here in terms of
schema support; the only caveat is that adding columns with default
values will cause a full rewrite of the table, for a time proportional
to its size.

For this reason, it’s recommended you always create new columns with
null=True, as this way they will be added immediately.

MySQL

MySQL lacks support for transactions around schema alteration
operations, meaning that if a migration fails to apply you will have
to manually unpick the changes in order to try again (it’s impossible
to roll back to an earlier point).

In addition, MySQL will fully rewrite tables for almost every schema
operation and generally takes a time proportional to the number of
rows in the table to add or remove columns. On slower hardware this
can be worse than a minute per million rows - adding a few columns to
a table with just a few million rows could lock your site up for over
ten minutes.

Finally, MySQL has reasonably small limits on name lengths for
columns, tables and indexes, as well as a limit on the combined size
of all columns an index covers. This means that indexes that are
possible on other backends will fail to be created under MySQL.

SQLite

SQLite has very little built-in schema alteration support, and so
Django attempts to emulate it by:

• Creating a new table with the new schema
• Copying the data across
• Dropping the old table
• Renaming the new table to match the original name

This process generally works well, but it can be slow and occasionally
buggy. It is not recommended that you run and migrate SQLite in a
production environment unless you are very aware of the risks and its
limitations; the support Django ships with is designed to allow
developers to use SQLite on their local machines to develop less
complex Django projects without the need for a full database.

当django-south中的迁移失败时，开发人员鼓励您不要使用MySQL：

要添加到以前的答案：

• "MySQL可能会更好地支持全文搜索"

MySQL中的FULLTEXT索引是一个笑话。

• 它只适用于MyISAM表，因此您将失去ACID，事务，约束，关系，持久性，并发性等。
• INSERT / UPDATE / DELETE到一个较大的TEXT列(如论坛帖子)将重建索引的很大一部分。如果它不适合myisam_key_buffer，则会发生大IO。我已经看到一个论坛帖子插入触发100MB或更多的IO ...同时post表被排他性锁定！
• 我做了一些基准测试(3年前，可能是陈旧的...)，这表明在大型数据集上，基本上postgres全文比mysql快10-100倍，而Xapian比postgres快10-100倍(但没有集成)。

未提及的其他原因是非常智能的查询优化器，大量选择的连接类型(合并，散列等)，散列聚合，数组上的gist索引，空间搜索等，这可以在非常复杂的查询上产生极快的计划。

此应用程序是在您自己的服务器上还是由托管公司托管？如果您使用的是托管公司，请确保它们支持所选的数据库。

走了MySQL的道路，因为我对它很熟悉(并且很难找到一个合适的安装程序并快速测试postgreSQL的慢速"工作台"界面让我失望)，在项目结束时，经过几次部署后几个月，在查看备份选项时，我发现你必须支付MySQL的企业后台功能。最后得到了。

我不得不在Django中编写一些丑陋的怪物原始SQL查询，因为没有选择不同的每组来检索最新的每组查询。还看了postgreSQL的全文搜索，并希望我使用postgresSQL。

即使您熟悉MySQL，我也推荐使用PostgreSQL，但您的里程可能会有所不同。

如果您打算使用db分发代码，那么两个db之间存在重大的许可差异，这会影响您。 MySQL的客户端库是GPL，PostegreSQL是BSD之类的许可证，可能更容易使用。