2025年11月20日·1 分钟
拉里·埃里森与甲骨文：数据库、锁定与企业销售
用通俗语言解析甲骨文与拉里·埃里森如何通过数据库、切换成本、授权与企业级销售纪律打造持久财富。
用通俗语言解析甲骨文与拉里·埃里森如何通过数据库、切换成本、授权与企业级销售纪律打造持久财富。
拉里·埃里森的持久财富公式可以这样概括：卖一个关键任务数据库，把它包装在多年合同里，建立一台让“维持现状”比迁移更安全的企业销售机器。
这是一个关于甲骨文如何变得难以替换的商业故事——不是关于数据库内部细节的深度技术教程。你不需要知道 SQL 优化器如何工作就能理解甲骨文为何几十年成为现金机器。
“持久”并不意味着客户每次续约都很满意。它意味着甲骨文把自己定位为使得收入倾向于重复出现的供应方。
持久性表现为：
当数据库承载计费、库存、HR 或交易系统时，它不再只是另一个 IT 工具，而是一个依赖，而依赖是有粘性的。
1) 数据库作为基础。 甲骨文专注于“记录系统”层——最有价值的运营数据所在之处。
2) 锁定（有时是无意的）。 不仅是技术兼容性，还有多年来累积的流程、集成、培训和厂商特定功能。
3) 企业销售。 甲骨文不像消费级应用那样获胜。它凭借采购周期、高层关系和旨在延续关系的合同获胜。
这三者合在一起产生复合效应：每一笔新交易不仅仅是一笔一次性销售——它提高了未来多次付款的概率。
拉里·埃里森并非一开始就是软件名人。他早期的职业是编程工作与学习大型组织如何购买技术——缓慢、谨慎，并偏好看起来稳健的供应商。
甲骨文于 1977 年（最初名为 Software Development Laboratories）成立，带着一个明确的论断：软件中最大的金矿是向大型机构出售基础设施，而不是做一次性的定制系统。埃里森和联合创始人并没有去追逐早期的爱好者或消费市场，而是把目标对准需要运行工资、库存、计费与会计系统的公司和政府机构。
当时计算领域被大型主机和集中式数据主导。即便客户端-服务器架构开始出现，大型公司内部的默认假设仍然是系统必须可靠、可审计并且要有多年支持。
这种环境奖励能成为标准组件的软件——IT 团队可以围绕它构建。数据库完美契合：它们位于许多应用之下，触及关键数据，并为持续的维护和支持提供理由。
企业客户的购买方式不同于个人。他们通过委员会、采购流程和多年计划购买。这促使供应商强调：
这也改变了财务特征。一笔大型合同可以资助多年的产品工作，但它需要基于关系、证明与降低风险的销售动作。
甲骨文的早期赌注很直接：赢得在企业运营核心的位置，你卖出的不仅是软件——而是通过更新、支持和升级维持的连续性，随着依赖增长，组织会持续为此付费。
数据库是公司的记录系统：官方“真相”所在之处。客户账户、发票、库存数量、工资条目、发货状态——这些不只是文件，而是企业赖以收款、合规与日常运营的事实。
随着企业构建更多软件——ERP、CRM、计费、供应链——这些应用越来越共享相同的底层真相源。如果数据库不可用，读写这些记录的应用就无法工作。这就使得数据库成为中心依赖，而非“又一件 IT 工具”。
数据库变得有粘性，因为应用是围绕它们编写的。随着时间推移你会积累：
切换并不像替换一个表格工具那样简单。你必须迁移大量数据、保留历史、重新测试关键工作流，常常还要重写应用的部分代码。即便新选项更便宜，项目风险也可能超过节省的成本。
对于关键任务系统，担忧不是“这周慢一点”，而是会导致订单处理停止的停机，或迫使对账、退款和监管麻烦的数据丢失。
当糟糕一天的成本可达数百万或损害信任时，买家会变得保守。“能可靠运行”胜过“新且有前景”。
IT 部门的考核基于稳定性。这推动他们选择具有长期业绩、成熟工具和见过各种故障模式的支持团队的厂商。
一旦做了这个决定，数据库就成了其余栈的锚点——把应用、流程和预算都拉进它的轨道。
关系型数据库是一种存储业务数据（客户、发票、发货等）的方法——以表格（可类比为电子表格）形式存放并相互关联。你不用到处找文件，而是可以问“显示所有超过 30 天未付的发票”并迅速得到一致的答案。
SQL（结构化查询语言）是与关系数据库对话的通用语言。由于 SQL 被广泛教授并得到普遍支持，容易让人以为数据库产品是可以互换的。
但在真实公司里，关键不只是系统是否理解 SQL。差异化体现在它周边的一切：数据库在高负载下的行为、崩溃后的恢复方式、备份如何工作、权限如何管理，以及团队如何监控和调优性能。
甲骨文并不是在“卖 SQL”，而是在兜售关键任务系统持续运行的承诺。
即便竞争者功能相当，决定标准化使用某一数据库也会跨越团队、预算和数年的运营习惯。数据库一旦成为报表、集成和合规的中心，“差不多够用”的技术并不足以取胜。
市场主导地位通常反映产品质量、风险管理和销售执行的混合，而不是某个单一的杀手级功能。
甲骨文并不是坐等开发者刷信用卡。它学会了大公司如何真正购买：缓慢、谨慎、涉及多人。
企业采购是团体运动。一个典型交易牵涉 IT 领导、安全、财务、法务和将拥有该系统的业务部门。这意味着漫长的时间线、正式的需求和内部政治。
甲骨文利用概念验证（PoC）、参考客户和详尽的兼容性声明来迎合这一现实。PoC 不只是技术测试——它是帮助某位赞助人在会议上向其他人证明采购合理性的工具。
甲骨文建立了经典的基于账户的销售：专属销售代表、命名账户，以及在“ABM”流行之前就存在的季度业务回顾节奏。
目标不是第一次合同；而是成为下一个项目以及后续项目的默认数据库选择。与 CIO 或数据库团队建立的信任可以持续超越预算调整、组织重组，甚至短期的产品不满。
支持合同、认证（DBA、开发者）和系统集成商会制造势能。一旦公司培训了人员、批准了架构并有合作伙伴熟悉甲骨文，改变供应商就像增加风险。
合作伙伴也会影响 RFP 中的推荐内容、可用技能以及哪些平台被认为是“安全”的。
续约有时比新客户更重要。如果甲骨文嵌入到了核心系统，年度续约变成业务连续性的决策，而不是新的购买选择。这时定价、审计条款和合同结构开始像产品功能一样塑造行为。
（关于这种杠杆的运作机制，见 /blog/how-lock-in-works。）
供应商锁定不需要不良意图。它只是对供应商产品的依赖逐步增长，伴随随时间上升的切换成本。对于像数据库这样的核心系统，这种组合很强，因为数据库位于应用、报表、安全与日常运营之下。
当系统依赖难以在别处复制的能力时，就会产生技术锁定。在数据库中，这常表现为专有功能（特殊 SQL 扩展、性能提示、集群方法）、厂商特有的工具和与应用中间件的深度集成。
即便“只是 SQL”，真实部署也会积累存储过程、触发器、备份脚本、监控代理和自定义连接器。堆栈越多地针对某个数据库调优，干净迁移就越困难。
运营锁定关系到人和流程。团队在特定平台上接受培训，招聘具有特定认证路径的管理员，并围绕特定行为构建运行手册——比如故障切换如何工作、如何执行升级、什么是“正常”性能。
随着时间，合规模板和审计文档也会变得数据库专属：访问控制、加密配置、保留策略和事件响应步骤。切换供应商就意味着重新培训人员、重写流程并重新验证控制措施。
合同锁定把切换成本变成日历上的现实。多年期条款、捆绑支持结构、续约周期与企业范围协议会让“我们下季度再变更”变得不现实。
支持是一个大杠杆：一旦关键系统依赖厂商支持获取补丁和安全指导，放弃支持可能看起来像承担新的运营风险——尤其是当合同包含严格的使用定义和惩罚，使得部分迁移变得复杂时。
甲骨文的护城河不只是技术性的，也有财务层面——通过定价模型让数据库嵌入预算，如同嵌入系统本身。
甲骨文授权常以几种常见单位出售：
关键思想很简单：一旦数据库成为核心，增长往往会增加这些计量之一——更多核心、更多用户或更多功能。
当定价有很多旋钮——计量、例外、使用权、捆绑选项——谈判会倾向于更懂规则的一方。
复杂性也让客户难以对比若干年总成本，从而削弱了他们比较替代方案或自信进行迁移的能力。
像许多大厂商一样，甲骨文进行授权审查以确认客户按合同条款使用软件。若中立执行，审计能保护双方利益。
在实际操作中，审计也制造了财务风险：如果某种使用被解释为超配，客户可能需要迅速补交授权。
年度支持续约——通常与许可费的百分比挂钩——在新销售放缓时也能创造稳定收入。升级和新版本成为第二个杠杆：客户为保持当前、兼容和受支持而付费，强化了经常性的循环。
甲骨文从未缺过竞争。但不寻常的是，许多客户在评估替代后仍然续约。
早期，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 部署是在甲骨文数据库上设计、测试并支持的，那么最安全的采购选择通常是保持数据库与应用一致。
这种动态有时被称为拉动效应：应用销售增加了数据库销售（和续约）的可能性，因为当各部分对齐时可靠性、支持边界与升级计划更简单。
捆绑意味着把多个产品打包在一起——商业上或运营上——使得从同一供应商购买更多产品比拼凑替代方案更容易。
平台策略是长期版本：共享身份管理、监控工具、集成连接器和标准化部署模式。
对买家而言，上行是供应商更少、责任更清晰。权衡是每增加一层可能会在将来增加切换成本，因为数据库、中间件与应用开始作为一个互联系统运作。
几十年来，甲骨文沿着一条简单模式繁荣：出售大额一次性数据库许可，然后收取年度支持。向云的转变威胁到了这种节奏。客户不再必然购买永久授权并自行运行，而是可以从云厂商租赁基础设施与托管数据库——通常采购更快、扩容更容易、按月计费更清晰。
云平台改变了谁控制运行环境。如果你的数据库运行在别人的基础设施上——而且可选数据库唾手可得——定价能力和续约杠杆可能减弱。
云采用也推动财务团队偏向订阅支出，使得大型许可交易更难以正当化。
甲骨文采取了两条并行路径：
对买家而言，托管数据库确有吸引力：补丁与备份自动化、高可用实现更简单、容量无需漫长硬件周期即可扩展。
即便授权经济学转向订阅，当它减少停机风险并释放内部团队时，这样的权衡可能是合理的。
很少有大型公司会一次性迁移一切。常见情况是多年在本地运行关键 Oracle 工作负载，同时在云端构建新系统——有时在 OCI 上运行 Oracle，有时在其他云上运行，并在中间保持集成胶水。
甲骨文在这个混合世界中的目标很直接：在客户运行的任何地方都尽量保持默认数据库地位。
锁定往往不是厂商设下的陷阱，而是时间压力下的合理决策的副作用。目标并不是“永不承诺”——而是以清醒的眼光承诺，并保有一个你能负担得起的退出计划。
签约前做一个简短的“未来迁移”演练并把它当作真实项目定价。
小的合同条款可以制造大的切换成本。
重点关注 续约条款、支持价格上调 与 审计语言（什么会触发审计、通知期以及如何衡量使用）。同时确认你的部署模型——虚拟化、容器化、容灾与开发/测试——与合同定义一致。
使用基准测试在等量工作负载上比较替代方案，而不是看厂商宣传数字。按需调整许可以匹配当前使用与近期增长，而不是最坏情况预测。
争取使用透明度：清晰的度量、报告访问和自查权。
如果你需要帮助预测成本，把这与更广泛的供应商支出规划和内部分摊（见 /pricing）对齐。
当代的一个变化是团队能比以往更快地累积依赖。诸如 Koder.ai 的即时生成平台让你在几天而非几个月内生成网页应用（React）、后端（Go + PostgreSQL）和移动应用（Flutter）。
速度很强大，但相同原则适用：事先决定什么能保持灵活。实用的“反无意锁定”特性包括 源码导出、快照与回滚、以及可预测的部署/托管选项。（Koder.ai 支持上述功能，并提供规划模式以在生成大量代码表面前绘制需求。）
甲骨文的故事不只是“向大公司卖软件”。它是一个关于产品如何成为组织永久部分的案例研究——以及这种永久性如何转化为持久的经济价值。
甲骨文不是靠做一个可有可无的产品取胜。数据库成为关键数据的宿主，业务围绕这一现实塑造自己。
如果你要做企业公司，寻找具有以下特征的切入点：
警告同样重要：你越是中心，就越需要赢得信任。如果客户感觉被困住却没有持续得到价值，他们最终会把你设计掉。
甲骨文表明伟大的企业业务往往是续约机器，而不是永远追新用户。高切换成本能稳定收入，但最好信号是客户在有选项时依然选择续约。
关注点包括：
锁定不仅是技术性的——也是运营与合同性的。谈判灵活性的时机是在你尚未陷入依赖之前。
实用举措：
甲骨文确实交付了真实价值：可靠性、性能和运行严肃业务的标准方式。代价在于当依赖限制了谈判能力或减缓变革时体现出来。
现代教训是：通过持续地赢得价值来变得不可或缺——同时为客户保留演进的路径。那样你才能获得长期关系而不制造长期怨恨。
“持久”意味着业务结构使得收入能够可靠地重复出现——即便客户并非每次都很满意。
在甲骨文的案例中，持久性来自于：
因为数据库位于让企业运转的系统之下：计费、工资、库存、交易、合规模式等。
当数据库是**记录系统（system of record）**时，停机或数据丢失会带来存在性的运营和监管风险——因此买家更重视稳定性和成熟的支持，而不是新奇性。
并非完全可替代。SQL 是标准，但企业并不是在买“语法”，而是在买结果：正常运行时间、恢复能力、负载下的性能、安全控制、工具链和支持。
两个产品都“支持 SQL”，但在以下方面可能差别很大：
切换成本会随着时间复合增长。
常见来源包括：
即便替代方案更便宜，迁移风险也可能抵消节省的成本。
甲骨文是向委员会和漫长采购周期出售，然后把账户当作长线关系来经营。
典型策略包括：
在甲骨文的模式下，续约往往是杠杆最大的时候。
如果数据库支撑核心业务，续约成为一个业务连续性决策，而不是一次重新评估。这会把讨论从“我们要不要买？”转为“我们能否安全地变更？”，而后者要困难得多。
这也是定价条款、审计条款和支持策略产生重大影响的阶段。
三层互相强化：
这些层面共同把切换成本变成现实的障碍。
甲骨文的定价往往有多种“计量器”，增长通常会触发至少一个计费维度。
常见的杠杆包括：
实际风险在于复杂性使得多年度总成本难以预测，也更容易无意中违反合规。
审计（或授权审查）是对合同条款的核对，以确认使用情况与购买相符。
实际上，它会带来：
降低风险的方法是跟踪部署情况、了解度量定义（虚拟化、灾备、开发/测试等），并保持清晰的内部使用报告。
不一定自动削弱——云只是改变了锁定的形态。
托管数据库可以减少运维负担（打补丁、备份、高可用），但仍需关注：
许多企业会多年处于混合状态：在本地运行关键 Oracle 工作负载，同时在云里构建新系统，Oracle 的目标是无论客户在哪里运行都成为默认数据库。