一口气了解甲骨文：AI机房的钱从哪来？

2026年9月10日，甲骨文公布了新一季财报。云基础设施收入约74亿美元，比上年同期增长121%，也就是翻了一倍多。同一个季度，它购买设备等长期资产花了约285亿美元。日常经营收到的钱扣掉相关现金支出后，净流入约231亿美元，这就是经营现金流，仍然少于前面的设备等投入。

甲骨文的收入增长很快，建设投入也在增加。它早期的核心产品，是企业用来保存和查询业务记录的软件。卖软件出身的公司，怎么走到了要提前买芯片、等供电、盯施工这一步？

30秒看懂

• 这家公司是谁：甲骨文从数据库起家，后来卖企业管理软件，现在也提供云服务和AI算力。
• 最近的大新闻：2026年9月10日公布的财报中，云基础设施收入同比增长121%，成为增长的主要推力。
• 钱从哪来：软件许可、后续支持、应用订阅，以及客户使用云端机器和数据库支付的费用。
• 反转点：合同越大，交付前需要准备的设备和资金也可能越多。客户预付款缓解压力，建机房仍然要先拿出现金。
• 本文只回答一个问题：甲骨文怎样从持续收费的软件，走到需要提前投入资金的AI算力生意？

开始之前，先解释几个关键名词，后面看不懂了随时翻回来查。

三个工程师，把论文做成生意

下面我们来从头介绍这家公司。1977年，拉里·埃里森、鲍勃·迈纳和埃德·奥茨创办了甲骨文的前身。迈纳主要负责产品开发，埃里森逐渐把更多精力放到销售上，他们盯上的机会来自一篇关于数据库的论文。

数据库到底解决什么问题？假设一家商店要同时处理订单、库存和退款，软件得知道哪笔钱对应哪件货。店员修改订单时，仓库也可能正在减库存，系统必须尽量保证各处记录能够对上。数据多起来以后，靠人打开文件逐份查找，业务就很难顺利运转。

研究人员埃德加·科德提出了一种组织数据的方法：把信息放进有关系的表里，让软件能够按需要组合查询。它的重要之处，在于业务程序不必总跟着底层数据存放方式一起改。这个想法先有学术基础，甲骨文创始团队看到了把它做成商业产品的机会。

1979年，甲骨文推出商用数据库产品。后来，公司又推动同一套产品在不同厂商的电脑上运行。客户采购硬件时多了选择，甲骨文也能把软件卖给更多已经拥有不同设备的企业。

这段创业故事里，我更在意的是分工。技术负责让产品运转，销售负责找到愿意付钱的客户，两件事缺一件都做不成长久生意。但销售跑得快，也会放大交付跟不上的问题，甲骨文后来确实吃过这个亏。

订单多了，公司就稳了吗？并没有。1990年前后，甲骨文遭遇严重经营危机，早期员工在口述历史里提到产品问题、客户不付款和管理混乱。公司后来引入杰夫·亨利、雷·莱恩等职业管理者，整顿财务和运营，才逐步稳住经营，让公司能够继续发展。

把这条路放到一起看，甲骨文的成长一直伴随着业务范围扩大。数据库帮它进入企业，应用软件让它参与更多日常工作，云服务又改变了交付方式。每次扩张都带来新收入，也增加了一种需要自己负责的事情。

公司买下更多产品后，客户的工作也越来越多地留在它的软件里。接下来的问题就很具体了：这些产品怎么收费，客户为什么愿意持续付钱？

客户留下来，服务费年年收

甲骨文到底卖什么？从企业里一个普通员工的工作看，会更好理解。销售要登记客户，财务要记账和结算，人事要计算薪酬，采购要知道货什么时候到。甲骨文既卖支撑这些工作的数据库，也卖直接完成这些工作的管理软件。

它通过收购仁科等公司扩大应用产品线，逐渐从技术部门的供应商，变成更多业务部门的供应商。一家企业原本只用它保存数据，后来可能连人员管理和采购流程也采用它的产品。同一个客户有更多需求，公司就有更多可以继续销售的服务。

传统的软件许可，可以理解成按合同买到某个范围的使用权。企业如果还需要更新、故障支持等服务，往往继续支付支持费用。甲骨文的支持政策通常按年度收费，因此早年卖出去的软件，也能产生后续收入。

这笔钱的重要性，可以看最近一个完整财年。2026财年，甲骨文软件支持收入约198亿美元，软件许可收入约47亿美元，前者约为后者的4倍。两项放在一起，才看得清老业务为什么能长期提供资金，不能只盯着这一年新卖出了多少软件。

后来为什么又要卖订阅？企业也希望少花精力管服务器、装升级包和维护应用。软件通过网络提供以后，客户可以按产品模块、使用人数等约定购买服务，把一部分运维工作交给供应商。甲骨文的中国团队在面向出海企业的采访里，谈过这种采购方式对小团队的吸引力。

做化肥助剂的湖北富邦在多个国家经营，财务系统要处理不同国家的会计规则，还要核对集团内部公司的交易，避免重复计算。实施服务商汉得记录，这家公司技术团队人数不多，自己部署和维护系统有压力，因此选择了甲骨文的云应用。对这家客户来说，采购软件要解决的是财务处理和维护人手的实际问题。这个案例来自参与实施的服务商，不能据此推断所有客户都能取得相同效果。

不过，公司自己也得改变做生意的习惯。过去谈一张大的软件订单，签下来就很显眼；订阅模式把收入摊到后续服务期，客户还会持续判断值不值得续费。

把几种收入分开，就不会把所有带“云”的东西都当成出租AI芯片。企业应用、数据库和计算资源解决的是不同问题，收费办法也不完全一样。它们可以一起卖，但不能拿其中一项的增长，代替整家公司所有业务的表现。

换一家便宜的，不就行了吗？有些企业确实在换，开源和国产数据库也提供了更多选择。但数据库连着业务程序，数据搬走以后，程序能否正确运转，还需要检查。采购价格只是迁移这件事里的一部分。

国内开发者李明亮记录过一次迁移过程：团队先盘点哪些系统使用哪些表，再改变系统之间读取数据的方式。原来一个系统可以直接查询另一个系统的表，改造后要通过对方提供的程序入口取数，这类入口就叫接口。随后还要逐步测试和切换，检查相关业务能否照常运转。迁移需要考虑的，是这些系统之间的依赖关系，以及改动后的业务结果是否正确。

这也是甲骨文客户关系的一部分基础。长期使用积累了流程、代码和人员经验，换供应商需要算全账。迁移很麻烦，也不代表客户永远不会走。当旧系统的费用和使用限制越来越难接受，客户也可能愿意花钱改造，替代方案便有机会成长。

把数据库送进对手的云

如果客户已经选了别家的云，甲骨文怎么办？过去很容易把问题理解成让客户二选一。可企业可能想保留熟悉的数据库，同时使用微软、谷歌或亚马逊的其他服务。强迫客户把所有东西搬到同一个地方，会增加采购和改造的阻力。

甲骨文后来给出了另一条路：把自己的数据库服务放到其他云厂商的数据中心里。微软在2023年公布相关合作，谷歌和亚马逊也陆续推出对应服务。客户能够在已有云环境附近使用甲骨文数据库，双方再把采购、网络和支持接起来。

为什么对手愿意一起做？因为共同客户有这个需求。甲骨文希望继续提供数据库服务，另一家云厂商希望客户把更多应用和计算任务留在自己的平台。具体的区域、采购和计费安排各有差别，但双方都有机会从同一个客户那里得到业务。

这样一来，客户选择其他云平台时，甲骨文仍有机会保留数据库收入，并参与后续升级。对客户而言，多一种组合办法，也就少一种为了使用某项服务而大规模搬家的压力。

这个变化在中国市场也有另一种表现。甲骨文接受国内记者采访时提过，客户使用多种数据库越来越常见，公司因此继续提供数据同步等工具。企业采用了国产或开源数据库，并不意味着旧系统马上全部消失，中间往往存在共用和逐步迁移的过程。

技术上也确实有需要细查的地方。开发者DarkAthena在一次从甲骨文迁到另一款数据库openGauss的实践中，发现一种更新数据的写法在原系统可运行，到了目标系统报错，随后做了多种验证。这个案例只说明特定版本和写法存在差异，不能推成某一类数据库普遍不行。

这算什么值得学的本事？我会把它理解成持续跟着客户的工作走。客户需要多种工具配合，供应商就让自己的产品更容易接进去。产品最容易留下来的地方，往往是它能稳定解决问题的那个环节，没必要要求客户先接受你全部的产品。

当然，配合也有边界。跨平台之后，谁负责哪一段故障、网络怎么计费、数据怎样退出，都需要提前讲清楚。选项变多是一件好事，责任边界含糊却会把便利变成新的沟通成本。

靠数据库服务，甲骨文还能继续做老客户的生意。本季收入增长最快的是云基础设施。要提供这类服务，它需要准备好机房、设备和运维团队。

接下AI订单，再把机房盖出来

AI公司为什么要找甲骨文？训练和运行大型模型需要大量计算资源，还要让许多芯片快速交换数据。客户可以自己建设，也可以采购云服务，把部分硬件、网络和运维工作交给服务商。甲骨文的云基础设施业务，通常简称OCI，提供的就是这类能力。

机房里放进很多GPU，还不能自动变成好用的算力。芯片之间如果传输慢，计算任务就可能等数据；供电、散热和维护跟不上，昂贵的设备也无法稳定运转。甲骨文的技术资料把网络互联和隔离设计列为重点，硬件合作伙伴也在参与扩大这些设施。隔离，就是把不同客户使用的资源和访问权限分开。

这条业务线在这一轮生成式AI热潮之前就已存在。早在2020年，视频会议公司Zoom就在需求快速增加时采用甲骨文云服务，同时继续使用其他云供应商。这个案例至少说明，甲骨文此前已经在承接大规模互联网服务的计算需求，后来又遇到了AI客户的扩张。

大订单是怎么来的？OpenAI与甲骨文围绕Stargate数据中心计划扩大合作，公开了新增设施和建设安排。它们描述的目标很大，但不同项目的建设阶段不同。规划、施工、接电和投入使用，需要分开理解，宣布了一个地点不等于那里已经能提供全部算力。

回到2026年9月10日的财报。这个季度截至2026年8月31日，公司总收入约193亿美元，其中云服务约116亿美元，已经超过一半。云基础设施约74亿美元，应用订阅约42亿美元，因此这次云增长里，提供机器、网络等基础设施的那部分尤其突出。

财报同时列出6640亿美元的待交付合同，超过公司2026财年约674亿美元收入的9倍。这个参照能帮我们理解合同规模，但不能理解成接下来9年的收入已经稳稳到手。合同会跨不同时间交付，具体确认收入的进度还取决于服务安排和实际履约。

签了合同，钱是不是就赚到了？签约只是开始，后面还要看交付、收款和实际成本。客户可能先付款，也可能按约定在以后付款；公司还需要提供服务，再按会计规则把相应部分记作收入。新闻里这几个数字经常一起出现，读的时候把它们分开，就能少很多误会。

甲骨文争取客户预付款、也允许部分客户提供硬件，都是在调整建设资金由谁先承担。这能够帮助它更早准备交付，但没有消除交付责任。接下来的考验，是设备到位以后能否持续使用，以及整个项目收到的现金，能否覆盖建设、运营和筹钱产生的费用。

先算现金，再看增长

增长这么快，为什么还要看现金？因为确认收入和收付现金的时间可能不同。公司会先为机房和设备花钱，服务收入随着交付逐步确认，客户付款又有自己的时间安排。短期有现金缺口不等于这门生意必然做不成，但缺口由谁补、需要补多久，会影响公司还能怎样扩张。

先把主要风险放在一起看。每一项都对应具体的后续信号。

这一季，经营现金流约231亿美元，里面包含约114亿美元、带有融资性质的客户预付款。仅这笔预付款，就接近当季经营现金流的一半，不能全看成当季服务已经赚回的现金。与此同时，购买设备等长期资产花了约285亿美元，两项相减，自由现金流约为负54亿美元。

数字放在一起，情况就清楚多了。客户愿意提前付款，说明建设压力不完全由甲骨文自己承担，这是有利条件。公司仍需为未来提供服务，也仍然存在投资支出超过经营流入的部分，所以预付款增加和现金问题解决不能画等号。

财报还显示，公司在这一季发行普通股，扣除发行费用后筹得约200亿美元，相当于当季约285亿美元设备等投入的70%。对公司来说，这是股东投入的资金；没有同步增持的原有股东，持股比例会下降。把这些来源分开看，才知道服务收入、客户预付款和股东投入，分别在怎样支撑扩张。

机房只要建起来，就一定有人一直用吗？这还要看客户产品有没有持续需求、模型效率怎样变化，以及下一批设备的性价比。算力需求可以增加，单位任务所需资源也可能下降，两种变化能够同时发生。对外宣布的长期目标，最终要一季一季落实到交付和收款里。

服务质量同样会影响续费。安全团队Wiz曾披露甲骨文云存储的一项隔离漏洞，甲骨文收到报告后进行了修复。研究人员发现的是可能导致跨客户访问存储数据的漏洞，不能据此认定已经发生数据泄露。企业购买云服务时，稳定性、权限和故障处理也都属于产品本身。

进入新行业，也不只是多卖一套软件。甲骨文收购Cerner后参与的医疗信息系统，涉及医护人员的工作流程、培训和实施安排。美国政府问责局在2025年评估退伍军人事务部的电子病历项目时，建议该部门更新成本估计和实施进度安排，软件合同与顺利落地之间还有很多工作。

Cerner这条线还牵涉医院怎么更换核心系统，为什么技术升级会影响一线工作的节奏，值得以后单独聊一期。这个案例让我更在意一件事：客户把越重要的工作交给你，你越需要证明自己能把后续服务做好。业务范围变大，管理和交付的难度也会跟着变大。

它到底做对了什么

普通人能从中学到什么？如果你的工作会接触AI工具，我觉得可以先留意一种能力：把工具放进真实流程，再检查结果。替同事做一个演示，比让同事每天放心使用容易得多。把输入从哪里来、结果由谁确认、错误怎样处理讲清楚，才有机会持续创造价值。

这也给想进入AI行业的人一条比较具体的路。可以从自己熟悉的采购、销售、客服或行政工作里，挑一个反复出现的小问题，记录现在怎么完成、哪里最费时间，再验证工具能否改善。把原来的流程、改动的办法和最后的结果记录清楚，就有了一份能向别人展示的实践。结果不好也有价值，至少能说明哪些问题还没有解决。

做AI产品的团队呢？甲骨文的经历里，我最想学的是跟着客户的需求扩大业务。客户先买一个功能，后来愿意把更多工作交给你，才有机会发展出持续收入。扩张过程中，销售承诺、产品能力和交付安排需要一起前进，销售承诺如果超过产品和交付能力，后续团队就得花时间补上差距。

中国团队做企业AI产品，也可以把这几件事放到第一次交付里。先选一个数据拿得到、效果能检查、失败后能处理的场景，给客户留出试用和退出的办法。等需求稳定下来，再判断哪些部分值得做成通用产品，哪些服务需要单独收费。

我尤其希望刚开始做产品的人，别因为眼前没有大客户、大合同，就觉得自己做的事情太小。企业每天愿意继续使用一个功能，本身就是需要认真对待的反馈。把一个具体环节做稳，让使用者少一次返工、少担心一次出错，这样的进步能够继续积累。

甲骨文从数据库走到AI机房，延续的是企业愿意为重要工作持续付费这件事。变化在于，为了拿到新一轮收入，它需要更早投入更多实物资产，也要承担更长的交付过程。这条路有机会，判断它是否走得顺，仍要回到客户使用、收入和现金。

接下来我会看，甲骨文建好的算力能否稳定交付，日常经营产生的现金能否逐步覆盖机房和设备投入。AI客户的实际需求和付款进度，能不能跟上这批机房的扩建速度？这个问题，我会一直盯着。

参考资料

1. Oracle Announces Q1 Results Driven by Triple Digit Growth in Cloud Infrastructure Revenues，Oracle Investor Relations，2026-09-10。
2. Oracle tops estimates as AI demand tempers cash-burn fears，Reuters（WSAU），2026-09-10。
3. Oracle Corporation Form 10-K, fiscal year ended May 31, 2026，Oracle，Form 10-K，2026-06-22。
4. About Oracle: A history of possibilities，Oracle。
5. Introduction to Oracle Database，Oracle Database 21c Concepts。
6. Databases / Oracle, CHM Revolution，Computer History Museum。
7. RDBMS Workshop: Oracle，Computer History Museum口述史，Ken Jacobs等早期员工，2007-06-12。
8. A Relational Model of Data for Large Shared Data Banks，E. F. Codd，Communications of the ACM 13(6), 377-387，1970-06。
9. Oracle Buys PeopleSoft，Oracle，2004-12-13。
10. Findings of Fact, Conclusions of Law and Order Thereon: U.S. v. Oracle，美国加州北区联邦地区法院，Vaughn Walker，2004-09-09。
11. Oracle Completes Acquisition of Sun，Oracle SEC Exhibit 99.1，2010-01-27。
12. Oracle and Cerner，Oracle交易资料页，2021-12-20公告，2022-06-08完成。
13. Oracle Announces Record Q4 and FY 2026 Results Driven by Cloud Infrastructure & Cloud Applications，Oracle，2026-06-10。
14. Stargate advances with 4.5 GW partnership with Oracle，OpenAI，2025-07-22。
15. OpenAI, Oracle, and SoftBank expand Stargate with five new AI data center sites，OpenAI，2025-09-23。
16. Microsoft and Oracle expand partnership to deliver Oracle Database Services on Oracle Cloud Infrastructure in Microsoft Azure，Microsoft，2023-09-14。
17. Oracle Database@AWS announces general availability, expands networking capabilities，AWS，2025-07-08。
18. Accelerating Cloud Transformation with Google Cloud and Oracle，Google Cloud，2024年6月。
19. First Principles: Baking security into the cloud，Oracle OCI技术团队，2021-06-18。
20. First Principles: Superclusters with RDMA：Ultra-high performance at massive scale，Oracle，Pradeep Vincent、Jag Brar，2023-02-14。
21. HPE and Oracle deepen networking collaboration to accelerate gigawatt-scale AI infrastructure，HPE，2026-09-02。
22. Oracle Software Technical Support Policies，Oracle，持续更新，访问日期2026-09-11。
23. Electronic Health Records: VA Making Incremental Improvements in New System but Needs Updated Cost Estimate and Schedule，U.S. Government Accountability Office，2025-03-12。
24. AttachMe: critical OCI vulnerability allows unauthorized access to customer cloud storage volumes，Wiz Research，Elad Gabay，2022-09-20。
25. OpenAI shows off Stargate AI data center in Texas and plans 5 more elsewhere with Oracle, Softbank，Associated Press，Matt O’Brien，2025-09-23。
26. Zoom Selects Oracle as a Cloud Infrastructure Provider for Its Core Online Meeting Service，Oracle，2020-04-28。
27. Zoom chooses Oracle IaaS as core cloud infrastructure provider，Computer Weekly，Brian McKenna，2020-04-29。
28. Are other industries struggling with SQL based reporting with Oracles push to go to the cloud?，Reddit r/oracle，2024年。
29. What are the predictions for Thursday’s earnings?，Reddit r/OracleStock，2026-09-10。
30. Oracle cut its Always Free ARM limits to 2 OCPU / 12GB, enforced Aug 18，Hacker News，2026年8月。
31. 36氪专访甲骨文公司：SaaS是最适合全球化企业的软件形态，36氪；王与桐、真梓、吴思瑾，2022-11-22。
32. 中国数据库领域竞争加剧，甲骨文放低姿态应对变化，界面新闻；彭新，2023-08-10。
33. 帮企业出海、搭建数据中台，甲骨文中国发力两大业务方向，界面新闻；彭新，2022-01-06。
34. 嘉年华专访吴承杨：你应该知道的甲骨文企业混合云，中国云报；郭涛；墨天轮转载，2016-11-25。
35. 专访“MySQL之父”：我曾创造MySQL，也将颠覆MySQL，InfoQ；李冬梅、王一鹏、刘燕，2022-10-16。
36. 比对手领先一步：访甲骨文公司大中华区区域董事总经理李翰璋，财富中文版；王亦丁，2006-10-01。
37. 甲骨文李翰璋：自治时代，云生态是趋势，经济观察报；沈建缘、邓晓蕾，2018-11-19。
38. 甲骨文吴承杨：AI时代拒绝空谈，评判核心看Outcome，e-works数字化企业网；王阳，2026-08-07。
39. 甲骨文CEO告诉你向云端转型的关键逻辑，RFID世界网；宁川，2017-10-11。
40. 专访马克·赫德：甲骨文将成最大SaaS厂商，DOIT传媒，2012-07-27。
41. 李翰璋：甲骨文的核心竞争力，数字商业时代；丁海骜；Oracle中国搜狐转载，2019-11-18。
42. 甲骨文2025开年抖新料，原生AI架构与英伟达打通，称ISV不重构将淘汰，智东西；徐豫，编辑心缘，2025-01-19。
43. 三次浪潮：从OceanBase看国产数据库的崛起，DoNews；李信马，2025-11-28。
44. Oracle总部采访记：不愿再与IBM比较，ITValue/钛媒体；丁娅琳，2014-04-14。
45. 出海背后：业务国际化与管理本地化的均衡，白鲸出海；智婷，2022-09-26。
46. 汉得x富邦：通过Oracle Fusion和EPM云，提升业务效率与绩效管理整体水平，汉得信息，2022-03-02。
47. 对话甲骨文公司副总裁谢鹏博士：全面数智化大背景下，云和数据库该怎样融合发展？，InfoQ；李冬梅，2022-10-28。
48. 没必要非得固守纯向量数据库！专访亚马逊云科技数据库和迁移副总裁Jeff Carter，InfoQ；采访Kevin，编辑Tina、蔡芳芳，2023-12-07。
49. 独家揭秘陆金所去Oracle全过程：18个月将90%数据库业务换到MySQL，InfoQ；田晓旭，2020-02-24。
50. 超大型金融机构国产数据库全面迁移成功实践，InfoQ；刘伟光、张俊宝，2022-08-01。
51. 20刀好兄弟PolarDB：论数据库该卖什么价？，冯若航；VONNG作者个人网站；Pigsty创始人，2024-04-25。
52. Vastbase V3.0.9PSU0 Oracle兼容性实测报告，Digital Observer；All China Database Union；墨天轮原创，2026-04-09。
53. WinServer2025安装OracleDB 19.27实测及applyRU问题复盘，徐sir；墨天轮原创，2025-06-10。
54. 从Oracle到PostgreSQL，某保险公司迁移实践，章晨曦；老鱼笔记；墨天轮转载，2019-11-03。
55. Oracle迁移到PostgreSQL改造详情，邓琼；中电福富；开源软件联盟PostgreSQL分会；墨天轮全文，2020-09-02。
56. DataX迁移oracle数据到PostgreSQL，IT那活儿；墨天轮转载，2020-08-07。
57. Oracle迁移PostgreSQL之开发篇，李明亮；保险技术黑板报；墨天轮转载，2021-09-13。
58. 【ORACLE】你以为的真的是你以为的么?：ORA-38104: Columns referenced in the ON Clause cannot be updated，DarkAthena；云和恩墨技术服务团队；墨天轮原创，2025-04-22。
59. 自建Oracle迁移至PolarDB PostgreSQL版兼容Oracle，阿里云技术文档，2025-03-14。
60. 迁移OceanBase数据库Oracle租户至Oracle数据库，OceanBase OMS技术文档，2026-05-14。

AI重度使用者｜每天拆一家前沿公司｜imluna.ai免费订阅｜Learn in Public