Note that here we are only looking at ODBC vs. Our general answer is that data volume should determine the data movement paradigm. We set out to test that advice with a simple database population (loading) benchmark. ETL (extraction, transformation, and loading).Our users often ask when it’s better to use ODBC or an off-line, flat-file approach to data handling - for which IRI is best known - during very large database (VLDB) operations like: But their ODBC driver may not be yours, and your mileage will vary. … Microsoft’s testing has shown that the performance of ODBC-based and DB-Library–based SQL Server applications is roughly equal.Īccording to Oracle, their ODBC driver, on average, runs only about 3% slower than native Oracle access. This assumption is true for some ODBC drivers implemented over a native DBMS API, but the Microsoft SQL Server ODBC driver is not implemented this way. This translation effort adds extra processing compared with having the application call directly to the native API.

This reasoning is based on the assumption that ODBC drivers must be implemented as an extra layer over a native DBMS API, translating the ODBC statements coming from the application into the native DBMS API functions and SQL syntax. In Using ODBC with Microsoft SQL Server, Amrish Kumar and Alan Brewer say ODBC is as good as native: One of the persistent rumors about ODBC is that it is inherently slower than a native DBMS API.

Microsoft disagrees in the case of SQL Server. ODBC gets a bad rap for speed sometimes … but should it? You’d think from what’s posted online that ODBC is intrinsically slow:

Oracle odbc driver for sql server