MySQL
　　MySQL的优缺点已经为许多人所知道：它是一个快速的、轻量级的数据库，但是基本上可以为大多数的网站服务得很好。
　　
　　无论如何，如果你计划在一个高流量的站点（说明，每天生成多于500，000页）上，那么忘了MySQL吧。因为它往往会崩溃或者在装入运行后死机。任何曾经访问过Slashdot的人都可以证明它的弱点。（mod_perl and MySQL)
　　
　　话说回来，MySQL证明了可使极大多数网站的页生成速度最高在每秒15页。如果你经常地运行在每秒15页之上，那么你将会非常高兴地支付更大的服务器或者Oracle license的费用。
　　
　　优势
　　明显地，MySQL胜过Postgres的优势就在于性能。而且在它的发行版中，还具有一些强有力的管理工具。（其中一些工具允许你察看进程并且可以在程度运行时进行动态调试。）比如热备份，文件毁坏恢复工具等。
　　
　　我也非常热衷于MySQL的命令行工具。你可以使用描述和察看命令来观察数据库与表的结构。而Postgres的命令则明显地少(/d可以显示一张示范表）
　　
　　局限性
　　从数据库行家听说的第一件事就是MySQL缺乏transactions，rollbacks， 和subselects的功能。如果你计划使用MySQL写一个关于银行、会计的应用程序，或者计划维护一些随时需要线性递增的不同类的计数器，你将缺乏transactions功能。在现有的发布版本的MySQL下，请不要有任何的这些想法。（请注意，MySQL的测试版3.23.x系列现在已经支持transactions了）。
　　
　　在非常必要的情况下，MySQL的局限性可以通过一部分开发者的努力得到克服。在MySQL中你失去的主要功能是subselect语句，而这正是其它的所有数据库都具有的。换而言之，这个失去的功能是一个痛苦，但是它可以被克服。
　　
　　稳定性
　　MySQL在长期使用的稳定性上失了分。比如，MySQL在运行了30-60天左右的时间后，没有理由地就放弃了随机ghost。许多开发者使用"statically"来编译MySQL就是为了这个原因，而且这个方法帮助了许多人。这个问题也可以通过设置一个好的调度程序让MySQL每月被杀死并重起一次来克服。这并不是一个完全可取的方法，但至少也是一个办法。
　　
　　MySQL在守护进程的健壮性上也失了分，但这个缺点被MySQL从来不会出现不可靠的数据文件而弥补。最后一件让人担心的事就是你重要的数据文件会不期地出错，而MySQL却很好地解决了这一点。在一整年的运行MySQL之后，这从未见过数据文件或索引文件轻易地出错。而在同样的时间内，我已经为一些Postgres数据库做了2-3次的恢复了。（记住，备份永远是你最好的朋友，这点可以从PHPBUILDER数据的崩溃看出）
　　
　　PostgresSQL
　　Postgres的测试结果可能会使许多人感到惊奇，尽管Postgres在一些网站开发者中声誉并不怎么好（最初的Postgres的发布版本中除了对落后的性能以外，而对其他部分大肆散布谣言）。但根据我的经验和测试，这些不良声誉并不完全有理由。实际上，PostgresSQL可以承受3倍于MySQL的负载而且没有任何错误，当然在相同的硬件和系统环境下。
　　
　　Postgres一般运行在 10页/每秒的速度之上，足够为 400，000页/每日的流量服务，假定一个规则的流量曲线峰值2倍于最小值。这是一个可怕的数量，它远远地超过了大多数人要在他们的网站上看到的数量。此外，网站的大多数页没有这次测试中的那么复杂。正如MySQL的情况一样，如果你可以超过这个最高限度，你将会非常乐意地花钱添置硬件。由于Postgres的结构，如果你增加处理器和内存，那么它的性能可以继续增长。
　　
　　优势
　　Postgres有一些非常高级的功能。而其中的大多数功能我并不使用，它们被真正的数据库高手所采用。许多开发者不利用这些功能，从而无法实现他们的想法。
　　
　　例如，如果你正需要做多次的更新/插入/删除操作，你可以利用transaction。比如，你要在你的用户列表中插入一个新的用户，同时在另一个表中，要插入一行，而且也要更新别处的一个标志。假如这样，如果第一次插入成功，而第二次失败，你怎么办？在Postgres中，你可以回退全部操作，而观察出错的缘由。而在MySQL中，出错时你会非常紧张，除非你安排了一些逻辑可以控制这个局面。在实际应用中，第一个问题不会出错，除非你是一个糟糕的程序员。而如果第二个问题出错，那么这个结果并不非常严重。（除非这是一个不允许出错的而冒险的程序，比如会计、银行业、评论界的应用程序。）
　　
　　无论如何，在Postgres7。0+中现在已经支持了外部关键字，那就意味着当你插入一行，数据库会做一些公正而合理的校验检察。同样，如果你要删除当前表一行，而有另一个表依赖于当前表，数据库则不会让你操作。我喜欢这个想法并且能预见如何利用这个功能重写整个网站。
　　
　　Triggers 和Views是能够在Postgres中，而不是在MySQL中使用的有趣而有用的工具。尽管我都没有使用过，但我可以想象如果我重新设计SourceForge时将如何地频繁利用views。
　　
　　局限性 <br>Postgres的主要局限性并不是它的性能（因为大多数网站将永远不会陷入这个问题）。但是由于编码硬化的限制，像每行8k的限制（日期会回到以前的时期）。当我使用Postgres设计Geocrawler.com，我不得不将大的e-mail分成每8k一块以绕过这个僵硬的限制。在默认情况下，Postgres被编译成只支持32个连接，这是不足以用来作高流量网站应用的，特别是考虑到Postgres生成每页的速度要比MySQL慢。
　　
　　另一个限制可警惕许多PHP的用户：Postgres没有与MySQL的mysql_insertid()等价的函数调用。如果在MySQL的数据库中插入一行数据，MySQL将返回这行主关键字的ID。而在Postgres中完成这样一个操作需要绕许多圈子，这是一件非常头痛的事，而且如果用的多可能会降低效率。
　　
　　稳定性
　　Postgres在长时间运行的情况下运行流畅而不出错。我的Postgres 6.5.3装在又老又累的PowerMac 8500上，无错运行已经有90天了；而且每天生成50-100，000页。当Postgres装入运行，不会退出，而在压力下不需要ghost。
　　
　　Postgres有一个问题是当你确实发生问题时，一般它就真坏了。在一些旧的Postgres6.4.x中，我还发现了更加严重的问题：许多重复而相同的数值被插入到同一个主关键字中（这是不允许在任何情况下出现的）
　　
　　Postgres还有另一问题就是会出现令人紧张的不完整的索引和表，你不能略过或摆脱它。我在Postgres7中没有再发现过它，但我没有对其全面使用，所以无法知道更多。
　　
　　结论
　　这次测试几乎证实了我所知道的：两个数据库系统都可以为大多数网站非常好地服务。它们与桌面数据库，像FileMaker和MS Access相比，非常明显地快。Postgres 和 MySQL都是自由而免费的，而且有积极的开发团体所支持。
　　
　　如果要在两者间选择一个，你首先需要明白你面临的限制并且知道你是否需要Postgres的transaction的支持或者MySQL的large-text-area支持。你可能都要，这种情况下，你只有等到将来的某一天，两者推出新的稳定发布版。
　　
　　需要提出的一件非常有趣的事是：这两个数据库似乎会在某处重合，就是当MySQL具有transaction的支持并且慢慢加入一些新的功能如：subselect，而Postgres在执行性能和稳定性上有所改进时。
　　
　　最后，作为数据库高手选择，Postgres应当非常灵活。外部关键字，views，subselects，和transactions都非常地棒--如果你需要并且应用它们。如果你不需要或不使用这些功能，你最好使用MySQL，而利用它优越的性能。