复杂SQL(优化引擎)
SQL是你与你的数据库交互的基础和最关键的方法，无论你选择哪个。这三个平台也恰恰是从它开始真正分离。Oracle支持非常复杂的查询、几乎不限制表的个数、所有的类型的连接和合并。虽然Oracle有很多功能，但是它真正宝贵的却是它基于成本的优化器，它可以分析SQL、如果可能的话进行重写和简化、基于成本选择索引、决定对表的操作和它之中的所有其它的各种功能。
阅读MySQL的文档，你会发现对偏向于性能的描述和供应商定义的细节使优化器和性能调整在任何平台上都很复杂。MySQL规定的最大规模是在任何连接或在一个视图中表的最大数目为61个。再一次的，我个人觉得无论如何在任何一个应用中这么多表的一个查询将是难以使用的，所以正如上面提到的，目前更适用的是优化器而不是查询最大表规格，等等。
8.x版本的Postgresql支持所有SQL92规范，几乎没有任何限制。再一次的，我认为你会看到的一个数据库优于其它的数据库的方面就是在优化方面。复杂的查询会变得凌乱，并且查询计划是你在诊断性能瓶颈时的最好的朋友。
索引类型
索引技术对于数据库性能是至关重要的，而Oracle有大量的选项可供选择。有非常多的不同的索引类型，包括标准的二进制树、转换键的、基于功能的、常被错误使用的位图索引，甚至还有索引表。随着附加项技术的发展，数据库管理员有了可用的提供索引的Oracle文本，它允许你搜索CLOB(字符大对象)，并且Oracle Spatial提供用于基于位置的数据的索引。
在MySQL中，我们发现有二进制树、哈希、纯文本和GIS索引(对于基于位置的数据)。还有集群索引，但是如果说我在Oracle方面的经验给我任何指导的话，那么就是大多数应用通常是不相关的。因此，大多数情况下我在Oracle、MySQL或Postgres应用中看到的只有二进制树索引。另外，尽管像在MySQL中基于功能的索引是不可用的，但是他们可以通过创建另一个保存使用这个函数的数据的列来进行模拟，然后添加一个触发器来将安装它。
Postgresql提供二进制树和哈希，还有R树，和它自己定制的GiST索引类型，GiST索引类型允许使用用户定义的类型和允许创建基于功能的索引。Oracle提供了一个类似的功能性类型，它的基于功能的索引可以用于基于pl/sql的功能而不只是标准的预定义系统功能，例如你本来可能会使用的trunc、UPPER。要小心像这样的索引可能访问起来非常缓慢，你可能在谈论到要录入或移除数据时，甚至不希望听到“慢”这个词。
它确实实现了，并且优化器选择索引的方式优于Oracle。
审计
Oracle使你可以对一个表或一个文件进行审计，通过审查索引工具。一旦允许了，你可以审查对某一个表的插入、更新或删除，或者登录，或甚至是某一特定用户的所有访问。它有许多选项，并且设置为可用的是非常简单的。
Postgresql也有这个功能，并且它看起来和Oracle的一样灵活和可配置的。
另一方面MySQL看起来没有提供这个功能，但是你当然可以创建你自己的存储过程和触发器来做你想做的，并录入相关的信息到数据表里，这只需要一点额外的工作。
数据类型
Oracle、MySQL和Postgresql都支持最大达到4GB的大型的二进制和文本数据。我们所知道并喜欢的所有的数据类型也是非常有用的，例如数字、字符和日期。每一个都在一定程度上提供一些定制数据类型，尽管我很少看到在应用中使用这些。
现在我要讲的一件事是Postgresql和MySQL已经超过了过去的基础，不用担心它们实现我们经常使用的一个良好的自增长列类型。Oracle的争论是按顺序来做这项工作更加有效，但是是静态的。Oracle也没有SET数据类型，这个数据类型很重要。它也没有只有时间的时间数据类型，这个数据类型Postgresql和MySQL都有。但是你会发现你能在这三个数据库品平台上做所有你想做的关于日期和时间的操作，从对时区的操作到对间隔的处理，等等。
另外一个我喜欢Postgresql和MySQL的理由是它们支持各种优秀的数学数字类型，从smallint到decimal、real、double，等等。这些利用了基本的架构实现，与编程语言中可用的数据类型相匹配，例如C语言。
对事务的支持
在数据库领域，适当的事务操作遵守了acronym到ACID，这意味着原子性、一致性、隔离性和持久性。原子性意思是一个事务是一个完整的单元，所有都被提交或所有都被回滚。一致性意思是你从一个*VALID*状态转移到另一个，例如你执行适当的约束来加强业务逻辑。隔离性意思是一个事务不能看到另一个事务在做什么，直到它完成了(提交了)。持久性意思是一旦提交了，这个变更就是永久的，并且是防止你硬盘失败的*至关重要的*。
关于这个问题我有一些事情要说，希望能够避免争论。我看到像“任何企业级应用绝不会使用一个没有实现完全的ACID遵从性的数据库，而且非事务型的表是完全没有用的”这样的说法已经消失了。这些都是愚蠢的说法。例如，Oracle在它的数据字典中的它本身的性能视图就不是事务型的。其次，它们在那个环境中根本没有必要。有许多应用是这样的。我看过一个航空票务系统，它需要定期升级和添加第二个服务器用于放置Oracle。他们看了这个软件的所有相关的许可成本和大型设备的硬件成本。然后他们回头看这个应用。有些人正确的认识到在航空网站上90%的操作是浏览航班(只读)，而仅仅10%才是真正的购买机票。所以，他们建立了一组低成本的MySQL服务器用于浏览航班，而变更旅程请求则提交给大型的Oracle服务器来执行票务操作。多么好的一个结合解决方案!