关于物理复制
　　我的下一个关注点是原文有关于 PostgreSQL 的物理复制（Physical Replication）。原文谈到「索引再平衡」话题的原因是 Uber 曾经遇到了 PostgreSQL 的复制错误，这导致了下游服务器的数据毁损。（这个错误值“影响了 Postgres  9.2 的一些特定版本并且已经修复了一段很长时间”）。
　　因为 PostgreSQL 9.2 只在 core 提供物理复制，复制错误“只造成了树的很大一部分变得彻底无效。”具体解释为：如果一个结点分裂进行错误的重复，那么它不能指向正确的子结点，这些子树将会变得无效。这是正确的，正如其他警言“如果存在一个 Bug，那么不好的事情会发生”。你不需要改变大量的数据，可以打破树的结构。一个单独的坏指针足够了。
　　Uber 的文章提到了其他关于物理复制的情况：大量的复制流量—一部分由于更新带来的编写增幅—并且故障时间需要更新到新的 PostgreSQL 版本。如果第一个对于我而言是由意义的，那么我是不能评论第二个的（但是这里仍有 statements on the PostgreSQL-hackers mailing list ）。
　　后，原文也声明了 Postgres 并没有真正的 MVCC 支持副本。幸运的是，原文链接到了 PostgerSQL 的文档，里面这个问题得到了解释。这个问题基本上是主机并不需要知道副本做了什么，并且因此会删除数据，而这些数据仍然需要副本来完成查询。
　　根据 PostgreSQL 官方文档，有两个办法可以处理这个问题：
　　1.为可配置的超时延迟复制流的应用，以便读取事务有机会完成。如果查询没有按时完成，杀死这个查询，并且继续应用这个复制流。
　　2.配置副本，把所有正在运行的查询，反馈送回到主机（master），这样一来主机并不需要清空行版本（row versions），恰好这些行版本在一些从属（slave）中仍然需要。Uber 的文章对第一个版本制定了规则，但根本没提第二个版本。相反，原文指责了 Uber 的开发人员。
　　关于开发者
　　以荣誉之名引用这段话：“举例来说，开发者有一些数据需要将发送给用户。取决于代码是如何写的，这些代码可能隐含有一个数据库事务，同时执行不相关的 I/O 阻塞，事实上是许多工程师都不是数据库方面的专家，因此不能总是理解这些问题，尤其是当使用 ORM 时，ORM 隐藏了许多底层细节，比如 open transactions 。”
　　不幸的是，我理解甚至同意这个评论。但是我不认同“许多工程师不是数据库，是因为每一个开发人员接触 SQL 是需要了解 transaction 的 ，不只数据库专家。”
　　鉴于对开发人员进行 SQL 培训是我的主要工作。我在各种规模的公司做过这件事。如果说我能确定一件事，那是和数据库相关的知识低的离谱。比如在刚刚提到的“open transaction”，我能确定的是，很少有开发人员知道只读事务是真事。大多数的开发人员只知道 事务可以用于回写。我遇到太多这种误解了，所以我准备了幻灯片来解释。
　　关于成功
　　这是我想写的后一个问题。一个公司雇佣的员工越多，他们的资质越趋于平均。夸张一点说，如果你雇佣了整个星球上的人员，你将会拥有的平均水平。雇佣再多的人，只是增加了公司的规模。
　　这里有两种方法来击败这种比率：
　　1、只雇佣好的员工。这个方法难的部分是，当没有高于平均资质的候选者时，需要等待。
　　2、雇佣一般的员工，然后在工作上培训。这对于新员工来说，需要一段很长的热身时间，并且可以结合现有员工进行培训。这两个方法的共同问题是需要时间。如果你没有时间——因为你的公司在快速增长——你不得不接受平庸，接受一些不是很了解数据库的人（ empirical data from 2014 ）。换句话来说：对于一个快速增长的公司来说，技术比人更容易改变。
　　正如随时间改变着的需求，成功的因素也会影响技术栈。在初期阶段，创业公司需要创造性的技术，即可以立即获得并且足够灵活来用于业务中。 SQL 一个比较好的选择，因为它确实灵活（你可以用任何方法来查询你的数据）并且很容易找到理解 SQL 的人，哪怕只对 SQL 有一点点了解。好了，那么开始吧！然而对许多—或许大多数公司来说，故事在这里结束了。即使他们比较成功并且他们的公司成长了，他们也可能在 SQL  的局限中永远处于原地踏步。Uber 不这样。
　　一些幸运的创业公司终从 SQL 蜕变。随着这种情况的发生，他们会有更多的机会访问资源并且然后…一些奇妙的事情发生了：他们意识到，如果他们开发一个只为自己使用的专用系统来取代通用数据库，他们可以解决许多问题。这是一个全新 NoSQL 数据库诞生的时刻。在 Uber ，他们将之称为 Schemaless 。
　　关于Uber 的数据库选择
　　直到现在，我相信 Uber 没有像他们的文章所建议的使用 MySQL 取代 PostgreSQL 。看来他们确实在一些特定的方法上替换了 PostgreSQL ，而这些方法恰好是 MySQL / InnoDB 所支持的（在当时）。看来原文只是解释了为什么 MySQL/InnoDB 比 PostgreSQL 更好地支持 Schemaless 。对于在用 Schemaless 的人来说，采纳他们的建议！不幸的是，原文并没有明确这一点，因为它并没有提及，和 2013 年从 MySQL 迁移到 PostgreSQL 相比，他们的需求是如何随着 Schemaless 的引进而改变的。
　　可悲的是，Uber 那文章留在读者脑海中的事情，是 PostgreSQL 很差劲。