Enterprise data rarely resides in one platform. Analytical data may be managed in Snowflake, customer-facing applications may run on MySQL, and operational or departmental systems may rely on Azure SQL. Until now, bringing these datasets into an AI and analytics workflow often meant creating duplicate copies, building incremental-ingestion pipelines, and maintaining separate governance paths.
AI Data Platform external catalogs now expand beyond the Oracle ecosystem by introducing Snowflake, Azure SQL, and MySQL as external catalog sources. Users can register these systems in AI Data Platform, discover their schemas and data objects, and use approved datasets directly in notebooks through a consistent three-part naming convention: catalog_name.schema_name.object_name.
This is more than another connector. It positions AI Data Platform as a centralized metadata and data layer across your organizations data ecosystem and helps improve developer productivity. Organizations can extend existing data investments into analytics and AI/ML use cases without making large-scale migration or data duplication a prerequisite.
Why Bring Existing Data Platforms into AI Data Platform?
Most enterprises have made significant investments in more than one data platform, and those platforms continue to serve important roles. Snowflake may be the established analytical warehouse, Azure SQL may support departmental and line-of-business systems, and MySQL may power customer-facing applications and digital services. Replacing or migrating these environments is rarely a practical prerequisite for advancing AI and analytics.
External catalogs let organizations bring these existing data investments into the AI Data Platform experience without creating duplicate datasets or maintaining separate incremental ingestion workflows. Instead, teams can discover externally managed data, understand its schemas and columns, and use approved objects from AI Data Platform notebooks.
This enables a more pragmatic path to modernization. Data engineers can build pipelines against existing enterprise data, analysts can expand cross-platform analysis, machine learning teams can access business data for models, and AI development team can develop AI agents. Meanwhile, the source platforms remain in place, preserving established operational architectures and their native governance controls.
AI and ML teams can use governed business data to build predictive models, GenAI applications, and data-aware agents. Catalogs give these agents access to trusted operational and analytical context without requiring every source to be copied first.
Some common use cases include:
- Customer-support agents grounded in MySQL account, product, order, and service data to answer questions and accelerate case resolution.
- Sales and account-management agents that combine Snowflake customer intelligence with MySQL product-usage signals to identify opportunities and recommend next actions.
- Financial-assistance and case-management agents that use Azure SQL business records to guide users through eligibility, application, or exception workflows.
- Operations agents that monitor inventory, subscriptions, orders, or service events in MySQL and help teams investigate issues faster.
- Analytics copilots that query curated Snowflake datasets to explain business performance, surface trends, and provide metric-backed recommendations.
- Data-engineering agents that help users discover schemas, interpret column metadata, validate source data, and accelerate development of new data products.
In each case, AI Data Platform provides the environment to build, ground, and operationalize agents while the underlying data remains in its established platform.
For data leaders, the result is a unified approach to data and AI adoption across hybrid and multi-cloud environments, one that builds on what the enterprise already has rather than requiring a disruptive, all-at-once consolidation.
Connecting Snowflake, Azure SQL, and MySQL with AI Data Platform external catalogs
AI Data Platform external catalogs extend existing Snowflake, Azure SQL, and MySQL investments into a unified data and AI experience, without requiring immediate migration or duplication. Teams can register each source, validate connectivity during onboarding, browse data objects, inspect metadata, and use them in AI Data Platform notebooks with the three-part convention
catalog_name.schema_name.object_nameFor Snowflake, users configure the account, database, warehouse, and key-pair authentication. Authorized users can browse schemas, tables, external tables, materialized views, and views, while Snowflake continues to manage its warehouse, data organization, and access model.
For Azure SQL, users configure the host, port, database name, username, and password. They can then discover schemas, tables, external tables, and views, making operational and departmental data available to AI Data Platform data engineering, analytics, and AI/ML workflows while Azure SQL remains the underlying operational platform.
For MySQL, catalogs are configured with a host, port, username, password, and SSL setting. Users can browse MySQL schemas, tables, and views to bring customer, product, service, and line-of-business context into AI Data Platform, while MySQL continues as the system of record for application-driven workloads.
Together, these external catalogs give data engineers, analysts, and AI/ML teams a governed way to work across distributed enterprise data, using each platform where it already delivers the most value.
What users can build?
External catalogs turn existing Snowflake, Azure SQL, and MySQL data into inputs for AI Data Platform data engineering, analytics, AI, and agentic workflows. Rather than first building a separate ingestion pipeline for every source, teams can begin by discovering and using authorized external data directly from AI Data Platform notebooks.
Data engineers can develop pipelines using enterprise datasets already managed in external platforms. They can explore schemas, validate source data, and create transformations or downstream data products, avoiding unnecessary duplication at the start of a project.
Analysts can combine operational and analytical context across platforms. For example, a Snowflake customer model can be examined alongside application data from MySQL or business-process data from Azure SQL, creating a more complete view of the business.
AI and ML teams can use governed business data to build predictive models, GenAI applications, and data-aware agents. Customer-support agents can use MySQL product, account, order, and service data to resolve requests with current operational context. Financial-assistance or case-management agents can use Azure SQL records to guide users through eligibility, application, or exception workflows. Sales and account-management agents can combine Snowflake customer intelligence with product-usage data to identify opportunities and recommend next actions.
External catalogs can also support operations agents that investigate inventory, subscription, order, or service-event issues, analytics agents that explain performance using curated Snowflake datasets, and data-engineering agents that help teams discover schemas, interpret column metadata, and validate source data. In every case, AI Data Platform provides the environment to build, ground, and operationalize these experiences while the underlying data remains in its established platform.
Governance and operational controls
AI Data Platform external catalogs are designed to make cross-platform data use manageable without treating connectivity as an unmanaged, one-time setup. Each catalog is a governed AI Data Platform object with a defined source type, connection configuration, discoverable metadata, and permission model.
Connection validation is built into the onboarding flow. For Snowflake, Azure SQL, and MySQL catalogs, users should successfully test the connection before creating the catalog. This helps teams catch configuration, credential, and network issues before data is used in notebooks or downstream workflows.
Access is controlled at the catalog level. Administrators can grant or revoke external catalog permissions, while authorized users can browse the schemas and supported objects exposed by each source. AI Data Platform surfaces object metadata including column names, data types, and descriptions, so users can understand an external dataset before using it. Users can also remove an external catalog when it is no longer needed. Together, these controls provide a consistent lifecycle for external data access across AI Data Platform, while the external platform continues to manage the underlying data.
Conclusion: Modernize without disruption
Conclusion: Modernize Without Disruption
External catalogs give organizations a practical way to extend existing Snowflake, Azure SQL, and MySQL investments into AI Data Platform. Rather than making migration and duplication the starting point, teams can register external data sources, govern access, discover schemas and objects, and work with approved data in AI Data Platform notebooks.
This enables a phased path to modernization. Data engineers can build against enterprise data where it already resides, analysts can expand their view across platforms, and AI/ML teams can develop models using governed business data.
AI Data Platform becomes the open layer that connects these distributed environments, bringing data engineering, analytics, machine Learning, and agent capabilities closer to the data, while allowing each source platform to continue serving the role it already performs well.
For more information
We covered recently introduced external catalog sources in Oracle AI Data Platform today. To explore more, check out these resources below: