Google's TPUs and Snowflake are coming to Oracle Cloud. One contract for rivals is not portability
Oracle will host Google TPUs from 2027 and offer Snowflake as a native OCI service, both billed through Oracle. That simplifies procurement and data movement. It does not make workloads portable.
Listen to this article · 5 min
AI-generated narration of the full article.
Until this week, choosing Google’s TPUs meant choosing Google Cloud, and choosing Snowflake meant running it on AWS, Azure or Google Cloud. On October 27, Oracle announced that both will be available on Oracle Cloud Infrastructure, bought from Oracle.
Does that make the enterprise AI stack portable? Partly, and in a narrower way than the headlines suggest.
What was announced
Google TPUs on OCI. Oracle and Google Cloud will deploy TPUs in OCI data centers “starting in the calendar year 2027,” which Google says makes OCI “the first hyperscaler outside Google to offer TPUs.” The announcement does not say which TPU generation, how customers will consume it, in which regions, or at what price. Its performance figures describe Google’s TPU line in general, such as up to 80% better performance per dollar for low-latency serving, and are Google’s own claims.
Snowflake as a native OCI service. Snowflake AI Data Cloud will be offered as a first-party OCI service. Customers will buy and provision it through Oracle, with one commercial relationship, unified billing, and the ability to use Oracle Universal Credits. Oracle names Fusion Applications, NetSuite, Autonomous AI Database, MySQL HeatWave and NoSQL Database as sources, and says keeping the data movement inside OCI reduces cross-cloud transfer and egress costs. No launch date, regions or pricing were given, and Oracle’s disclaimer says product direction is not a commitment.
Before and after, for a company running Oracle applications
Before: finance and supply chain data sat in Oracle Fusion on OCI. Analytics ran in Snowflake on another cloud, fed by pipelines that paid egress and needed their own security review. Model training or serving on TPUs meant a third relationship with Google Cloud. Three contracts, three sets of credits, data copied twice.
After, when it ships: the same company could keep Oracle data, Snowflake and TPU capacity inside one provider’s data centers and one commercial agreement. Fewer pipelines across clouds, one place to spend committed credits, and possibly lower egress.
That is a real improvement in procurement and data movement. We described how procurement, not benchmarks, increasingly shapes the AI stack; committed cloud credits are now a currency that rivals accept.
What it does not change
Portability of the workload. Code written for TPUs is not automatically portable to GPUs, and a Snowflake deployment on OCI is still Snowflake. What moved is where you can buy them, not how tied you are to them.
Who operates what. When a rival’s product runs inside another provider’s cloud, two companies share the operation. We saw this with Claude on Google Cloud, where the choice is who processes your data. For TPUs on OCI, nothing yet says who operates the accelerators, who handles incidents, or whose terms govern the data. Ask before you plan workloads around it.
Concentration. Consolidating three providers into one contract also consolidates the dependency. Oracle becomes the commercial front door for chips, data platform and applications. That may be the right trade, but it is a trade.
Questions for the account team
- For TPUs on OCI: which generation, which regions, which consumption model, and who operates the hardware?
- For Snowflake on OCI: which regions and features at launch, and is pricing different from Snowflake on other clouds?
- Can committed Oracle credits and existing Snowflake commitments be combined or converted?
- Which company’s data processing terms apply to data in each service?
Until those answers exist, treat both as 2027 options in your model supply chain map, not as capacity you can count on.