Back to Blog

Connecting Power BI to Oracle Databases - Bundled Provider, Cloud, and Gateway Options

April 16, 2026•7 min read•Michael Ridland

Oracle databases are everywhere in Australian enterprise. Banks, government departments, insurers, mining companies - if an organisation has been running critical workloads for more than a decade, there's a good chance Oracle is involved somewhere. And when those organisations want to bring that data into Power BI, the connection setup has historically been one of the more annoying parts of the process.

For years, connecting Power BI to Oracle meant installing Oracle Client software on every machine that needed the connection. Desktop users needed it. Gateway servers needed it. The 32-bit vs 64-bit versioning had to match exactly. It was fiddly, error-prone, and generated more support tickets than it should have.

Microsoft has been steadily making this easier. There are now four different ways to connect Power BI to Oracle, and picking the right one depends on where your Oracle database lives and how your team works. At Team 400, we deal with Oracle-to-Power-BI connectivity regularly, so here's what we've learned about each approach.

Option 1 - The Bundled Oracle Provider (Preview)

This is the one I'm most excited about. Power BI Desktop now includes a built-in Oracle Managed ODP.NET provider. No separate Oracle Client installation required.

To enable it, go to File > Options and settings > Options > Preview features and turn on:

  • Enable Oracle Bundled Provider for Import Mode
  • Enable Oracle Bundled Provider for DirectQuery Mode

Restart Power BI Desktop, and you can connect to Oracle databases using the built-in provider. That's it.

Why does this matter? Because the single biggest friction point in Oracle-Power BI projects has always been the client software installation. In large organisations, installing Oracle Client means an IT service request, change management approval, compatibility testing, and a two-week wait. With the bundled provider, a report developer can connect to Oracle data in minutes.

The catch: it's in preview. For production reports that feed executive dashboards, some organisations will want to wait until it's generally available. My take is that the underlying ODP.NET library is mature and widely used - Oracle's managed provider isn't experimental technology. Microsoft wrapping it into Power BI is low risk. But I understand the caution, especially in regulated industries.

If you're doing exploratory analysis or building prototypes, use it now. For production workloads in environments where preview features make compliance teams nervous, the Oracle Client for Microsoft Tools is still the stable path.

Option 2 - Oracle Client for Microsoft Tools (OCMT)

OCMT is Oracle's official installer for configuring ODP.NET for Microsoft tools. It's a graphical installer, it supports both 32-bit and 64-bit, and it works with Power BI Desktop, the on-premises data gateway, Excel, SSAS, SSDT, SSIS, SSRS, and BizTalk.

Download it from Oracle's OCMT page. Make sure you match the bitness to your Power BI Desktop installation. If you're running 64-bit Power BI Desktop (which you almost certainly should be), get the 64-bit OCMT.

The installation itself is straightforward. Where it gets tricky is in environments with multiple Oracle tools already installed. If you have an existing Oracle Client, tnsnames.ora files, or environment variables pointing to a different Oracle Home, OCMT can conflict with those. I've seen cases where OCMT installed cleanly but Power BI still couldn't connect because an old Oracle Instant Client was shadowing the new provider in the PATH.

My advice: on machines dedicated to Power BI development or gateway hosting, keep the Oracle stack clean. One installation, one Oracle Home, clear environment variables. The fewer competing Oracle installations, the fewer mysterious connection failures.

Option 3 - Direct Cloud Connections (Preview)

This one is specifically for Oracle cloud databases - most commonly Oracle Autonomous Database. Instead of going through a gateway, the Power BI service connects directly to your Oracle cloud endpoint.

Setup happens in the Power BI service (not Desktop):

  1. Go to Settings > Manage connections and gateways
  2. Select New connection, choose Cloud
  3. Set the connection type to Oracle
  4. Enter the Oracle cloud server endpoint (the URL ending in .oraclecloud.com)
  5. Provide credentials and save

This supports both Import and DirectQuery modes.

The appeal is obvious: no gateway required. For organisations running Oracle Autonomous Database, this removes an entire infrastructure component from the architecture. No gateway server to maintain, patch, and monitor.

The limitation is equally obvious: this only works for Oracle cloud databases with publicly accessible endpoints (or endpoints accessible from Microsoft's network). On-premises Oracle databases behind corporate firewalls still need a gateway. Hybrid environments where some Oracle instances are on-prem and some are in Oracle Cloud will need both approaches.

I'd watch this capability closely. As more Australian enterprises move Oracle workloads to cloud (whether Oracle Cloud Infrastructure or third-party hosting), direct cloud connections will become the preferred path. The gateway was always a necessary workaround for network accessibility, not something anyone wanted to maintain for its own sake.

Option 4 - On-Premises Data Gateway

The established workhorse. If your Oracle database is on-premises and behind a firewall, the on-premises data gateway is how Power BI reaches it.

Install the enterprise gateway on a server that has network access to the Oracle database. Install 64-bit OCMT on that same server. Configure the data source in the Power BI service.

A few things we've learned from gateway deployments:

Use the enterprise gateway, not the personal gateway. Personal gateways don't support Oracle connections. This catches people occasionally, especially individuals who set up a personal gateway for other data sources and assume it works for everything.

Network access matters. The gateway server needs to reach the Oracle database on the appropriate port (usually 1521 for the listener). In segmented networks, this might require firewall rules or VPN configuration. We've spent more time debugging network connectivity between gateway servers and Oracle databases than debugging the actual Power BI configuration.

Gateway clustering is worth the effort for production workloads. A single gateway server is a single point of failure. If it goes down, your scheduled refreshes stop. Two gateway servers in a cluster give you automatic failover.

Monitor gateway performance. Oracle queries against large tables can be slow, and if your gateway server doesn't have enough resources, refresh times balloon. We've seen cases where adding RAM and CPU to the gateway server cut refresh times in half, because the bottleneck wasn't the Oracle database or the network - it was the gateway itself doing the data compression and transfer.

Supported Oracle Versions

Power BI supports Oracle Database 12c (12.1.0.2) and later, plus all versions of Oracle Autonomous Database. If you're still running Oracle 11g, you'll need to upgrade before Power BI will connect. Given that Oracle 11g reached end of extended support in 2024, this shouldn't be a surprise, but I mention it because we still encounter it in the wild.

Microsoft Entra ID SSO with Oracle

One more feature worth mentioning: Power BI now supports Microsoft Entra ID (formerly Azure AD) Single Sign-On for Oracle databases. This means users authenticate with their Entra ID tokens rather than Oracle database credentials.

Requirements are specific:

  • Oracle Database 19c Release 20 or later, Oracle 23ai, or Oracle Autonomous Database
  • Power BI Desktop June 2024 or later
  • Entra ID configured for your Oracle environment
  • On-premises data gateway (for scheduled refresh)

The security benefit is real. Instead of embedding Oracle credentials in the gateway data source configuration, users authenticate with their corporate identity. This means access auditing, conditional access policies, and credential rotation all happen through Entra ID rather than managing Oracle database accounts separately.

For organisations with mature identity management, SSO eliminates a credential management headache. For smaller teams, the Entra ID configuration for Oracle is non-trivial and might not be worth the setup effort until you're managing more than a handful of Oracle data sources.

Which Approach Should You Use?

Here's my decision tree:

Oracle in the cloud (Autonomous DB)? Try direct cloud connections first. It's the simplest architecture. Fall back to the gateway if network restrictions prevent direct access.

Oracle on-premises? Use the on-premises data gateway with OCMT. This is the battle-tested path.

Developing reports locally? Enable the bundled provider preview. It removes friction from the development workflow even if production uses a different approach.

Multiple Oracle sources across cloud and on-prem? You'll likely need a combination. Direct cloud connections for cloud databases, gateway for on-prem. Plan your gateway capacity accordingly.

The full Microsoft documentation covers additional details including the Power Query connector reference and troubleshooting steps.

If you're planning a Power BI deployment that connects to Oracle - or if you're struggling with an existing Oracle connection that keeps failing - our team can help. Oracle connectivity is one of those areas where getting the architecture right from the start saves you weeks of troubleshooting later. We've also published guides on connecting Power BI to other data sources that you might find useful if Oracle isn't your only concern.