Teradata has integrated its Autonomous Knowledge Platform with Microsoft OneLake, letting enterprises run analytical queries and AI workloads directly on data stored in OneLake without copying it into Teradata first. The connection uses the open APIs of Apache Iceberg and Microsoft Entra ID for authentication, and is initially available with read access.
Teradata and Microsoft OneLake in 20 seconds
- Teradata can query tables stored in Microsoft OneLake directly.
- The integration avoids creating certain copies and ETL pipelines just to move data from one platform to another.
- It uses the Apache Iceberg APIs and authentication through Microsoft Entra ID.
- It lets teams combine data from Teradata and OneLake within the same analytical workload.
- For now, the announced integration offers read access to OneLake tables.
The announcement tackles one of the less visible problems in enterprise AI projects: before data can be used, it has to be located, copied, transformed, governed, and kept in sync.
A large organization may have information spread across corporate databases, analytical warehouses, data lakes, SaaS applications, and different cloud providers. When a new AI system needs access to that data, the traditional solution is to build yet another extract, transform, and load (ETL) pipeline.
The problem shows up once those copies start to multiply.
There’s more storage to pay for, more processes to maintain, and more permissions to manage. It also raises the odds that two systems end up working from different versions of the same information.
The integration between Teradata and OneLake tries to remove part of that journey: instead of bringing the data to the analytics engine, it brings the engine to the data.
Apache Iceberg starts working as a common language between platforms
The technical piece that makes this integration possible is Apache Iceberg, an open table format built for working with large analytical datasets.
Microsoft has been expanding Iceberg support inside OneLake. Its architecture can work with both Delta Lake and Apache Iceberg through metadata virtualization. Delta tables can be exposed to Iceberg-compatible readers, and Iceberg tables can be used from different Microsoft Fabric workloads.
OneLake also has a REST endpoint compatible with the Iceberg REST Catalog standard, initially aimed at read-only metadata operations.
Teradata taps into that open layer to access the tables.
The practical consequence is significant: a company that has information inside Microsoft Fabric doesn’t necessarily need to export it, transform it, and keep a second copy in Teradata to analyze it from that platform.
Users can run queries against OneLake tables and combine that data with information that already lives in Teradata.
That makes it possible, for example, to run complex joins, prepare features for AI models, or serve analytical queries with certain service-level requirements without first consolidating all the data into a single repository.
Interoperability doesn’t mean the two platforms become one, either. Teradata and Microsoft Fabric still keep their own engines, services, costs, and operating models. What changes is the need to physically duplicate certain information just to work with it.
Less ETL can mean lower cost and less duplicated data
For years, copying information between platforms has been standard practice in enterprise analytics.
The process works, but it comes at a cost.
A company might store an original dataset on one platform, keep another copy in a data lake, generate a third for an analytics system, and end up creating new versions again for machine learning projects.
Each copy consumes storage and needs to be kept up to date.
Pipelines also fail. Someone has to track schemas, credentials, processing windows, dependencies, and changes made in the source systems.
AI amplifies the problem because it can require huge amounts of corporate information to build features, retrieve context, or feed applications and agents.
Teradata argues that its integration removes that step for customers who work with both its products and Microsoft Fabric at the same time.
That claim needs to be read with some care: it doesn’t eliminate the general need for ETL or data movement across an enterprise.
Plenty of situations will still call for cleaning, transforming, copying, aggregating, or reorganizing information.
What can disappear is one specific type of movement: copying data from OneLake to Teradata purely because Teradata’s engine needs to analyze it.
That nuance matters a lot more than promising the end of ETL altogether.
Governance matters as much as saving on storage
Duplicating information also creates a security problem.
When a dataset is copied to another platform, someone also has to decide who can access that new copy, how users authenticate, which policies apply, and how its audit trail is maintained.
The announced integration uses Microsoft Entra ID to manage authentication between platforms. Teradata also says the access model preserves the governance framework tied to the data instead of having to rebuild it around every new copy.
Microsoft follows a similar philosophy inside OneLake itself.
Its shortcuts work as references to information stored elsewhere. They can point to data inside OneLake as well as to external sources such as Azure Data Lake Storage, Amazon S3, Google Cloud Storage, and Iceberg-compatible systems, among others.
In these cases, source permissions still matter. Microsoft’s documentation explains that access to shortcuts depends on permissions both where the reference sits and at the destination it points to.
The trend is clear: data platforms are trying to offer logical access to distributed information without turning every integration into a new physical copy.
A particularly interesting piece for AI agents
Teradata is tying this architecture to another of the big shifts underway in enterprise software: AI agents.
A useful agent inside an enterprise needs more than a language model.
It has to know which customer is asking, what their orders are, which contracts they hold, what products are available, or what internal policies it must respect.
Much of that knowledge is scattered across different systems.
Continuously duplicating all of that data into a specific AI platform can be expensive and hard to govern. Accessing it where it already lives offers an alternative.
Teradata’s Autonomous Knowledge Platform is specifically built to provide enterprise context, governance, and analytical capability for AI applications and agents. The connection to OneLake expands the amount of information it can use without requiring a migration first.
That doesn’t mean an agent can automatically access everything stored in Fabric.
Permissions are still required, and enterprise architecture still has to control what information each application can query.
Not every use case needs direct runtime access either. For certain systems it will still make more sense to prepare specific datasets in advance.
The advantage lies in having another option available.
OneLake reinforces its role as Microsoft Fabric’s common data layer
For Microsoft, the integration fits with OneLake’s original premise.
OneLake works as Microsoft Fabric’s common logical data lake. The company presents it as a layer where different analytics engines can work on the same information without each one necessarily keeping its own copy.
Adding support for open formats extends that idea beyond Microsoft’s own services.
Apache Iceberg matters especially because it’s being adopted by numerous analytics platforms and allows the storage format to be partly decoupled from the engine used to process it.
For enterprises, that separation can reduce one of the historical risks of large data platforms: that moving a workload to a different engine also means physically migrating enormous amounts of information.
Teradata’s integration is an example of how open formats are starting to be used to connect products that previously would have needed dedicated replication mechanisms.
The first version has one important limitation: it’s read-only
Teradata says the integration is available immediately, but it’s worth paying attention to its scope.
The integration currently provides read access to OneLake tables.
Teradata can query and analyze the information without modifying the data stored there.
This also matches the current state of OneLake’s Iceberg table APIs, whose documentation initially specifies read-only metadata operations.
So the announcement shouldn’t be read as a full two-way integration in which any operation run from Teradata can write directly back to Microsoft Fabric tables.
Even so, for many analytical workloads, read access alone can cover a considerable share of what’s needed.
An organization could keep certain data in OneLake, keep other data in Teradata, and analyze both together without launching a prior consolidation project.
Teradata will publicly demonstrate the integration at the European Microsoft Fabric + SQL Community Conference, taking place in Barcelona from September 28 to October 1, 2026.
The announcement reflects a broader shift underway in enterprise data architectures.
For years, integrating platforms mainly meant moving information from one to the other. The combination of decoupled storage, open formats, and standard catalogs is opening the door to a different architecture: keeping data where it makes sense to store it, and letting different authorized engines work directly on it.
At a time when enterprise AI needs to query more and more information, cutting down on copies can affect cost, latency, and governance.
And that’s probably the most interesting part of the Teradata-Microsoft integration: Apache Iceberg is starting to turn a data’s physical location into a decision less tied to whichever engine ultimately analyzes it.
For more on how Teradata’s platform is expanding into AI infrastructure, see our earlier coverage of Teradata bringing its intelligent AI platform to the cloud and data center.
Frequently asked questions
What has Teradata announced with Microsoft OneLake?
Teradata can now query and analyze tables stored in Microsoft OneLake directly from its Autonomous Knowledge Platform. The integration avoids having to copy that data into Teradata first just to analyze it.
Do you need ETL pipelines between OneLake and Teradata?
For the access announced here, you don’t need to replicate OneLake’s data into Teradata through an ETL pipeline. That doesn’t mean ETL stops being necessary for other transformations or integrations across an organization.
What role does Apache Iceberg play?
The integration uses Apache Iceberg’s standard APIs to let Teradata query tables stored in OneLake. Microsoft also uses Iceberg as part of its interoperability strategy across different data engines and platforms.
Can Teradata write directly to OneLake data?
The announced integration currently offers read access only. It lets you query and use the tables from Teradata, but it shouldn’t be confused with a full read-and-write integration.
