拉里·埃里森与甲骨文：数据库、锁定与企业销售

一句话概括的持久财富公式

拉里·埃里森的持久财富公式可以这样概括：卖一个关键任务数据库，把它包装在多年合同里，建立一台让“维持现状”比迁移更安全的企业销售机器。

这是一个关于甲骨文如何变得难以替换的商业故事——不是关于数据库内部细节的深度技术教程。你不需要知道 SQL 优化器如何工作就能理解甲骨文为何几十年成为现金机器。

这里“持久”是什么意思

“持久”并不意味着客户每次续约都很满意。它意味着甲骨文把自己定位为使得收入倾向于重复出现的供应方。

持久性表现为：

• 来自支持、维护和持续授权的经常性收入
• 高续约率，因为软件运行着核心业务
• 客户惯性，由风险、成本和组织习惯驱动

当数据库承载计费、库存、HR 或交易系统时，它不再只是另一个 IT 工具，而是一个依赖，而依赖是有粘性的。

我们会反复提到的三大支柱

1) 数据库作为基础。 甲骨文专注于“记录系统”层——最有价值的运营数据所在之处。

2) 锁定（有时是无意的）。 不仅是技术兼容性，还有多年来累积的流程、集成、培训和厂商特定功能。

3) 企业销售。 甲骨文不像消费级应用那样获胜。它凭借采购周期、高层关系和旨在延续关系的合同获胜。

这三者合在一起产生复合效应：每一笔新交易不仅仅是一笔一次性销售——它提高了未来多次付款的概率。

拉里·埃里森与甲骨文对企业软件的早期押注

拉里·埃里森并非一开始就是软件名人。他早期的职业是编程工作与学习大型组织如何购买技术——缓慢、谨慎，并偏好看起来稳健的供应商。

甲骨文于 1977 年（最初名为 Software Development Laboratories）成立，带着一个明确的论断：软件中最大的金矿是向大型机构出售基础设施，而不是做一次性的定制系统。埃里森和联合创始人并没有去追逐早期的爱好者或消费市场，而是把目标对准需要运行工资、库存、计费与会计系统的公司和政府机构。

企业计算的背景

当时计算领域被大型主机和集中式数据主导。即便客户端-服务器架构开始出现，大型公司内部的默认假设仍然是系统必须可靠、可审计并且要有多年支持。

这种环境奖励能成为标准组件的软件——IT 团队可以围绕它构建。数据库完美契合：它们位于许多应用之下，触及关键数据，并为持续的维护和支持提供理由。

向大组织销售如何改变商业模式

企业客户的购买方式不同于个人。他们通过委员会、采购流程和多年计划购买。这促使供应商强调：

• 与现有系统和工作流的兼容性
• 文档、培训和支持
• 可预测的路线图与长期合同

这也改变了财务特征。一笔大型合同可以资助多年的产品工作，但它需要基于关系、证明与降低风险的销售动作。

甲骨文的早期赌注很直接：赢得在企业运营核心的位置，你卖出的不仅是软件——而是通过更新、支持和升级维持的连续性，随着依赖增长，组织会持续为此付费。

为什么数据库成为企业技术栈的中心

数据库是公司的记录系统：官方“真相”所在之处。客户账户、发票、库存数量、工资条目、发货状态——这些不只是文件，而是企业赖以收款、合规与日常运营的事实。

每样东西都依赖的那个组件

随着企业构建更多软件——ERP、CRM、计费、供应链——这些应用越来越共享相同的底层真相源。如果数据库不可用，读写这些记录的应用就无法工作。这就使得数据库成为中心依赖，而非“又一件 IT 工具”。

数据库为何变得有粘性

数据库变得有粘性，因为应用是围绕它们编写的。随着时间推移你会积累：

• 针对业务流程定制的模式和存储逻辑
• 到报表、财务、数据导出与合作伙伴系统的集成
• 与某一产品匹配的运行手册、监控、备份例程与性能调优

切换并不像替换一个表格工具那样简单。你必须迁移大量数据、保留历史、重新测试关键工作流，常常还要重写应用的部分代码。即便新选项更便宜，项目风险也可能超过节省的成本。

停机和数据丢失如何改变购买行为

对于关键任务系统，担忧不是“这周慢一点”，而是会导致订单处理停止的停机，或迫使对账、退款和监管麻烦的数据丢失。

当糟糕一天的成本可达数百万或损害信任时，买家会变得保守。“能可靠运行”胜过“新且有前景”。

可靠厂商为何赢得核心位置

IT 部门的考核基于稳定性。这推动他们选择具有长期业绩、成熟工具和见过各种故障模式的支持团队的厂商。

一旦做了这个决定，数据库就成了其余栈的锚点——把应用、流程和预算都拉进它的轨道。

关系型数据库、SQL 与甲骨文实际上卖的是什么

关系型数据库是一种存储业务数据（客户、发票、发货等）的方法——以表格（可类比为电子表格）形式存放并相互关联。你不用到处找文件，而是可以问“显示所有超过 30 天未付的发票”并迅速得到一致的答案。

SQL 是标准——那优势在哪里？

SQL（结构化查询语言）是与关系数据库对话的通用语言。由于 SQL 被广泛教授并得到普遍支持，容易让人以为数据库产品是可以互换的。

但在真实公司里，关键不只是系统是否理解 SQL。差异化体现在它周边的一切：数据库在高负载下的行为、崩溃后的恢复方式、备份如何工作、权限如何管理，以及团队如何监控和调优性能。

企业买的是结果，而不是语法

甲骨文并不是在“卖 SQL”，而是在兜售关键任务系统持续运行的承诺。

• 可靠性重要，因为工资不能迟发，订单处理不能停止。
• 性能重要，因为慢的数据库会让每个应用感觉都坏了。
• 工具链重要，因为大型组织需要可预测的升级、诊断、复制、安全控制，并能在凌晨 2 点升级到厂商的支持。

主导地位并非纯粹技术因素

即便竞争者功能相当，决定标准化使用某一数据库也会跨越团队、预算和数年的运营习惯。数据库一旦成为报表、集成和合规的中心，“差不多够用”的技术并不足以取胜。

市场主导地位通常反映产品质量、风险管理和销售执行的混合，而不是某个单一的杀手级功能。

甲骨文的企业销售手册

甲骨文并不是坐等开发者刷信用卡。它学会了大公司如何真正购买：缓慢、谨慎、涉及多人。

向委员会而不是个人卖

企业采购是团体运动。一个典型交易牵涉 IT 领导、安全、财务、法务和将拥有该系统的业务部门。这意味着漫长的时间线、正式的需求和内部政治。

甲骨文利用概念验证（PoC）、参考客户和详尽的兼容性声明来迎合这一现实。PoC 不只是技术测试——它是帮助某位赞助人在会议上向其他人证明采购合理性的工具。

基于客户账户的销售与多年关系

甲骨文建立了经典的基于账户的销售：专属销售代表、命名账户，以及在“ABM”流行之前就存在的季度业务回顾节奏。

目标不是第一次合同；而是成为下一个项目以及后续项目的默认数据库选择。与 CIO 或数据库团队建立的信任可以持续超越预算调整、组织重组，甚至短期的产品不满。

支持、认证和合作伙伴作为决策引擎

支持合同、认证（DBA、开发者）和系统集成商会制造势能。一旦公司培训了人员、批准了架构并有合作伙伴熟悉甲骨文，改变供应商就像增加风险。

合作伙伴也会影响 RFP 中的推荐内容、可用技能以及哪些平台被认为是“安全”的。

续约：真正杠杆所在

续约有时比新客户更重要。如果甲骨文嵌入到了核心系统，年度续约变成业务连续性的决策，而不是新的购买选择。这时定价、审计条款和合同结构开始像产品功能一样塑造行为。

（关于这种杠杆的运作机制，见 /blog/how-lock-in-works。）

锁定如何运作：技术、运营与合同层面

供应商锁定不需要不良意图。它只是对供应商产品的依赖逐步增长，伴随随时间上升的切换成本。对于像数据库这样的核心系统，这种组合很强，因为数据库位于应用、报表、安全与日常运营之下。

技术锁定

当系统依赖难以在别处复制的能力时，就会产生技术锁定。在数据库中，这常表现为专有功能（特殊 SQL 扩展、性能提示、集群方法）、厂商特有的工具和与应用中间件的深度集成。

即便“只是 SQL”，真实部署也会积累存储过程、触发器、备份脚本、监控代理和自定义连接器。堆栈越多地针对某个数据库调优，干净迁移就越困难。

运营锁定

运营锁定关系到人和流程。团队在特定平台上接受培训，招聘具有特定认证路径的管理员，并围绕特定行为构建运行手册——比如故障切换如何工作、如何执行升级、什么是“正常”性能。

随着时间，合规模板和审计文档也会变得数据库专属：访问控制、加密配置、保留策略和事件响应步骤。切换供应商就意味着重新培训人员、重写流程并重新验证控制措施。

合同锁定

合同锁定把切换成本变成日历上的现实。多年期条款、捆绑支持结构、续约周期与企业范围协议会让“我们下季度再变更”变得不现实。

支持是一个大杠杆：一旦关键系统依赖厂商支持获取补丁和安全指导，放弃支持可能看起来像承担新的运营风险——尤其是当合同包含严格的使用定义和惩罚，使得部分迁移变得复杂时。

授权与定价：护城河背后的经济学

甲骨文的护城河不只是技术性的，也有财务层面——通过定价模型让数据库嵌入预算，如同嵌入系统本身。

用通俗的话讲授权

甲骨文授权常以几种常见单位出售：

• 核心（基于处理器）： 根据运行甲骨文的软件所用的计算能力付费。更多服务器或更大 CPU 通常意味着更高账单。
• 用户（命名用户加）： 按能够访问系统的人员（或账户）计费，通常有每服务器最低值。
• 版本： 不同层级有不同限制和功能，鼓励“升级以解锁”。
• 附加包： 额外功能（安全、性能调优、高可用、管理工具）单独定价，采用后难以撤回。

关键思想很简单：一旦数据库成为核心，增长往往会增加这些计量之一——更多核心、更多用户或更多功能。

复杂性为何有利于供应商

当定价有很多旋钮——计量、例外、使用权、捆绑选项——谈判会倾向于更懂规则的一方。

复杂性也让客户难以对比若干年总成本，从而削弱了他们比较替代方案或自信进行迁移的能力。

审计与合规检查

像许多大厂商一样，甲骨文进行授权审查以确认客户按合同条款使用软件。若中立执行，审计能保护双方利益。

在实际操作中，审计也制造了财务风险：如果某种使用被解释为超配，客户可能需要迅速补交授权。

支持续约与升级

年度支持续约——通常与许可费的百分比挂钩——在新销售放缓时也能创造稳定收入。升级和新版本成为第二个杠杆：客户为保持当前、兼容和受支持而付费，强化了经常性的循环。

竞争与为何客户仍然续约

甲骨文从未缺过竞争。但不寻常的是，许多客户在评估替代后仍然续约。

主要竞争时代

早期，IBM 是显而易见的对手：DB2 已经运行在许多企业的关键工作负载上。甲骨文的主张是跨硬件平台的可移植性和性能，这在企业摆脱对 IBM 主机依赖时很重要。

90 和 00 年代，微软 SQL Server 快速扩张，尤其在部门级和中端市场，因其简单性和较低价格经常被认为“足够好”。

随后开源变得有可信度以承担严肃工作。MySQL 在 Web 工作负载中占优；PostgreSQL 成为希望获得企业级特性又不想支付企业授权费用团队的首选。

为什么“足够好 + 更便宜”并不总能取胜

数据库并非孤立购买。它们被包裹进业务流程、报表、安全评审、合规签核与供应商关系中。节省授权费用可能是真实的，但经常会被重新测试应用、再培训人员和承担运营风险的成本所淹没。对许多公司而言，当系统正常工作时数据库最不显眼，而一旦出问题又最先被指责——这使得决策者更保守：他们宁愿多付钱也不愿成为“弄坏计费系统”的团队。

即便有能力的替代品，迁移为何仍旧困难

移动数据只是第一步。存储过程、SQL 方言差异、性能调优、备份/恢复例程、监控、第三方工具以及厂商认证的应用都可能依赖于甲骨文特有行为。即便合同与审计历史也会制造摩擦。

云托管数据库：新的压力来源

云服务把数据库变成更少旋钮的订阅：AWS RDS/Aurora、Azure SQL、Google Cloud SQL（以及 Spanner）降低了对专门 DBA 工作的需求，使“试用”更容易。这是真正的竞争——不是关于功能，而是关于降低切换成本。

甲骨文的回应是推广自己的托管服务，并主张在甲骨文自己平台上运行甲骨文数据库最安全。

从数据库厂商到企业套件：通过并购上移

甲骨文起家是数据库公司，但大型企业很少仅仅购买“一个数据库”。他们购买运行财务、HR、销售和运营的系统——这些系统会持续拉动数据库层的需求。

并购作为构建套件的策略

企业软件的常见模式是通过收购成熟的应用厂商扩展目录，然后向同一批高层买家推销更广的产品组合。供应商可以提供多个模块：一次采购、一个客户团队，且（常常）一个首选技术栈。

甲骨文通过并购逐步上移到业务应用（如 ERP、CRM）、中间件和其他基础设施产品。这并不保证无缝集成，但会改变客户评估厂商的方式：“我们能否在更多核心系统上标准化为同一供应商？”成为现实问题。

应用的拉动效应：ERP/CRM 如何提升数据库需求

一旦公司在供应商栈上运行关键应用，数据库就不再是单独的成本行，而是嵌入的依赖。如果某个 ERP 部署是在甲骨文数据库上设计、测试并支持的，那么最安全的采购选择通常是保持数据库与应用一致。

这种动态有时被称为拉动效应：应用销售增加了数据库销售（和续约）的可能性，因为当各部分对齐时可靠性、支持边界与升级计划更简单。

捆绑与“平台”的通俗说法

捆绑意味着把多个产品打包在一起——商业上或运营上——使得从同一供应商购买更多产品比拼凑替代方案更容易。

平台策略是长期版本：共享身份管理、监控工具、集成连接器和标准化部署模式。

对买家而言，上行是供应商更少、责任更清晰。权衡是每增加一层可能会在将来增加切换成本，因为数据库、中间件与应用开始作为一个互联系统运作。

云转变与甲骨文保持必要性的尝试

几十年来，甲骨文沿着一条简单模式繁荣：出售大额一次性数据库许可，然后收取年度支持。向云的转变威胁到了这种节奏。客户不再必然购买永久授权并自行运行，而是可以从云厂商租赁基础设施与托管数据库——通常采购更快、扩容更容易、按月计费更清晰。

为什么云是生存威胁

云平台改变了谁控制运行环境。如果你的数据库运行在别人的基础设施上——而且可选数据库唾手可得——定价能力和续约杠杆可能减弱。

云采用也推动财务团队偏向订阅支出，使得大型许可交易更难以正当化。

甲骨文的回应：成为云，而不只是运行在云上

甲骨文采取了两条并行路径：

• Oracle Cloud Infrastructure (OCI)： 构建一套第一方云，这样甲骨文不仅能卖数据库软件，还能出售计算、存储、网络与支持的捆绑。
• 托管数据库服务： 把 Oracle 数据库作为托管服务提供，让客户在把运营责任转给甲骨文的同时继续使用 Oracle。

“托管服务”真正带来的价值

对买家而言，托管数据库确有吸引力：补丁与备份自动化、高可用实现更简单、容量无需漫长硬件周期即可扩展。

即便授权经济学转向订阅，当它减少停机风险并释放内部团队时，这样的权衡可能是合理的。

大多数企业所处的混合现实

很少有大型公司会一次性迁移一切。常见情况是多年在本地运行关键 Oracle 工作负载，同时在云端构建新系统——有时在 OCI 上运行 Oracle，有时在其他云上运行，并在中间保持集成胶水。

甲骨文在这个混合世界中的目标很直接：在客户运行的任何地方都尽量保持默认数据库地位。

买家能学到的：避免无意中的锁定

锁定往往不是厂商设下的陷阱，而是时间压力下的合理决策的副作用。目标并不是“永不承诺”——而是以清醒的眼光承诺，并保有一个你能负担得起的退出计划。

购买前评估切换成本

签约前做一个简短的“未来迁移”演练并把它当作真实项目定价。

• 技能： 会有多少人接受甲骨文数据库特有功能的培训？你是标准化可移植 SQL，还是依赖专有工具和 API？
• 工具链： 哪些监控、备份、ETL 和安全工具会绑定到该厂商？检查是否存在替代品及其成本。
• 数据迁移： 测试代表性导出/导入（规模、停机、验证）。最难的通常是数据完整性、性能调优和应用重写，而不是复制本身。

需要关注的合同要点

小的合同条款可以制造大的切换成本。

重点关注 续约条款、支持价格上调 与 审计语言（什么会触发审计、通知期以及如何衡量使用）。同时确认你的部署模型——虚拟化、容器化、容灾与开发/测试——与合同定义一致。

降低锁定的谈判习惯

使用基准测试在等量工作负载上比较替代方案，而不是看厂商宣传数字。按需调整许可以匹配当前使用与近期增长，而不是最坏情况预测。

争取使用透明度：清晰的度量、报告访问和自查权。

如果你需要帮助预测成本，把这与更广泛的供应商支出规划和内部分摊（见 /pricing）对齐。

一个现代并行现象：速度也会制造锁定

当代的一个变化是团队能比以往更快地累积依赖。诸如 Koder.ai 的即时生成平台让你在几天而非几个月内生成网页应用（React）、后端（Go + PostgreSQL）和移动应用（Flutter）。

速度很强大，但相同原则适用：事先决定什么能保持灵活。实用的“反无意锁定”特性包括 源码导出、快照与回滚、以及可预测的部署/托管选项。（Koder.ai 支持上述功能，并提供规划模式以在生成大量代码表面前绘制需求。）

从埃里森与甲骨文得到的教训

甲骨文的故事不只是“向大公司卖软件”。它是一个关于产品如何成为组织永久部分的案例研究——以及这种永久性如何转化为持久的经济价值。

给创始人的建议：谨慎选择你的“记录系统”切入点

甲骨文不是靠做一个可有可无的产品取胜。数据库成为关键数据的宿主，业务围绕这一现实塑造自己。

如果你要做企业公司，寻找具有以下特征的切入点：

• 位于核心工作流（计费、身份、数据、合规）
• 随时间积累历史（产品越用越有价值且越难替换）
• 成为跨团队的共享依赖（而非某个部门的孤立工具）

警告同样重要：你越是中心，就越需要赢得信任。如果客户感觉被困住却没有持续得到价值，他们最终会把你设计掉。

给投资人的视角：持久性通常来自续约与惯性

甲骨文表明伟大的企业业务往往是续约机器，而不是永远追新用户。高切换成本能稳定收入，但最好信号是客户在有选项时依然选择续约。

关注点包括：

• 基于真实使用的扩展收入（而非仅靠合同压力）
• 嵌入流程与治理的产品
• 可信的现代化路径（以免惯性变成怨恨）

给运营者的建议：在仍有杠杆时规划退出

锁定不仅是技术性的——也是运营与合同性的。谈判灵活性的时机是在你尚未陷入依赖之前。

实用举措：

• 保持清晰的数据模型和文档，即便你从不迁移
• 避免单向集成；从第一天起设计 API 与导出
• 在长期规划中预留“迁移预算”（人员 + 时间）
• 定期复核合同条款：审计权、价格上调条款与续约窗口

平衡的观点：所交付的价值 vs. 依赖的成本

甲骨文确实交付了真实价值：可靠性、性能和运行严肃业务的标准方式。代价在于当依赖限制了谈判能力或减缓变革时体现出来。

现代教训是：通过持续地赢得价值来变得不可或缺——同时为客户保留演进的路径。那样你才能获得长期关系而不制造长期怨恨。