# OData datasource support

**URL:** <https://community.dremio.com/t/odata-datasource-support/442>\
**Category:** Uncategorized\
**Created:** [November 9, 2017, 8:53am UTC](https://community.dremio.com/t/odata-datasource-support/442 "2017-11-09T08:53:29Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![MikeWiese](https://avatars.discourse-cdn.com/v4/letter/m/aeb1de/32.png) [@MikeWiese](https://community.dremio.com/u/MikeWiese)\
**Post date:** [November 9, 2017, 8:53am UTC](https://community.dremio.com/t/odata-datasource-support/442/1 "2017-11-09T08:53:29Z")

</div>

This may be on the roadmap already but hey…

If Dremio supported an OData source, that would be a wonderful thing for all us system integrators who would love to deploy Dremio on client sites. With the current datasource support, there will always be those one or two data sources that Dremio can’t talk to that are crucial to a BI project. Weird and wonderful web APIs, industrial databases, obscure legacy systems, etc,…

Sure, we could do ETL, but that defeats the point of keeping data live, and having a single source of truth.

If Dremio supported an OData source then we could all get busy writing custom OData interfaces to expose our dodgy data sources, and there would be no more datasource-based blockers to adoption.

---

<div class="post-metadata">

**Author:** ![can](https://sea2.discourse-cdn.com/flex020/user_avatar/community.dremio.com/can/32/40_2.png) [@can](https://community.dremio.com/u/can)\
**Post date:** [November 21, 2017, 2:51am UTC](https://community.dremio.com/t/odata-datasource-support/442/2 "2017-11-21T02:51:34Z")

</div>

Hey @MikeWiese, thank you for the feedback. Agreed, we’ll never cover all the sources for all use cases. Our initial plan here is to introduce a Data Source SDK (timing TBD) to enable various types of custom high-performance connectors. At the same time, we are exploring various frameworks/options to simplify this process and enable faster turnarounds for some types of sources (e.g. web APIs). So far, OData hasn’t come up frequently, but we’re still investigating.

Out of curiosity, what would be the top sources you’d like to see in Dremio next?

---

<div class="post-metadata">

**Author:** ![MikeWiese](https://avatars.discourse-cdn.com/v4/letter/m/aeb1de/32.png) [@MikeWiese](https://community.dremio.com/u/MikeWiese)\
**Post date:** [November 21, 2017, 7:27am UTC](https://community.dremio.com/t/odata-datasource-support/442/3 "2017-11-21T07:27:01Z")

</div>

Hi @can, ODBC and OLEDB are the datasources that are blocking me from adopting Dremio, or recommending it to my clients. My industrial clients all have a variety of pretty standard Oracle and SQL Server systems, plus some kind of industrial historian (a specialised type of database optimised for time-series data). The various historians have a bunch of proprietary APIs, but in addition to that they almost always support ODBC and/or OLEDB.

One of the reasons I like the idea of OData is that it opens up a bunch of existing datasources via a nice REST API, but also because if it comes to a crunch, I can always build a custom OData facade over whatever hideously-ugly data repository I happen to be battling with at the time. I suppose I could also write facades with ODBC or OLEDB, but the idea of going back to C++ and COM is about as exciting as returning to black-and-white TV.

I’m not wedded to OData, but the ease with which I can write OData glue code is a big attraction (plus I tend to use BI tools that can consume OData). If you go in some other direction, that will be quite influential. As long as it works over port 80, and we can all write custom facades, then it should be a good thing.

---

<div class="post-metadata">

**Author:** ![can](https://sea2.discourse-cdn.com/flex020/user_avatar/community.dremio.com/can/32/40_2.png) [@can](https://community.dremio.com/u/can)\
**Post date:** [November 21, 2017, 10:22pm UTC](https://community.dremio.com/t/odata-datasource-support/442/4 "2017-11-21T22:22:58Z")

</div>

Hi @MikeWiese appreciate the details – makes sense. I’ve added your feedback to our internal tracking. We’ll reach out when there are developments on this front.

On a side note: At a high level, we’re currently focusing on making Apache Arrow a common interchange between different systems regardless if one of those systems is Dremio. This way, once you have, say, a X to Arrow integration, it not only benefits Dremio, but many other systems.

---

<div class="post-metadata">

**Author:** ![desi](https://avatars.discourse-cdn.com/v4/letter/d/a183cd/32.png) [@desi](https://community.dremio.com/u/desi)\
**Post date:** [November 15, 2020, 6:48pm UTC](https://community.dremio.com/t/odata-datasource-support/442/5 "2020-11-15T18:48:24Z")

</div>

Any progress on odata? More BI tools are using odata over jdbc now.

---

<div class="post-metadata">

**Author:** ![tshiran](https://sea2.discourse-cdn.com/flex020/user_avatar/community.dremio.com/tshiran/32/15_2.png) [@tshiran](https://community.dremio.com/u/tshiran)\
**Post date:** [November 16, 2020, 6:53am UTC](https://community.dremio.com/t/odata-datasource-support/442/6 "2020-11-16T06:53:47Z")

</div>

Are you referring to connecting to Dremio over ODATA, or having Dremio connect to ODATA sources?

The issue with ODATA is that it’s not SQL-based. You can’t push down the processing the way you can with JDBC or ODBC. It’s fine for pulling small amounts of data.

---

<div class="post-metadata">

**Author:** ![desi](https://avatars.discourse-cdn.com/v4/letter/d/a183cd/32.png) [@desi](https://community.dremio.com/u/desi)\
**Post date:** [January 29, 2021, 5:12am UTC](https://community.dremio.com/t/odata-datasource-support/442/7 "2021-01-29T05:12:09Z")

</div>

I am referring to connecting to Dremio over ODATA - so Dremio exposing VDS/PDS via ODATA.
