ODBC

ODBC (Open Database Connectivity) is a standard, database-agnostic API for connecting applications to relational database systems. It defines a common interface that an application calls, and a layer of database-specific drivers that translate those calls into whatever a given database understands. Originating from Microsoft and the SQL Access Group in the early 1990s, it let developers write data access code once and point it at many different databases without rewriting the application.

• Driver-based abstraction - A common API sits in front of database-specific drivers, so applications don’t hardcode the details of any one database.
• SQL as the common language - Queries are expressed in SQL and routed through the driver to the underlying engine.
• Cross-platform reach - Implementations exist across operating systems, and ODBC’s design inspired later abstractions like JDBC for the Java world.
• Direct, connection-oriented access - Clients hold a live database connection rather than talking to a web interface.

In modern API operations ODBC is mostly the thing an API is meant to replace at the edge. As I’ve written, exposing a database directly over ODBC or JDBC hands clients a low-level, tightly-coupled connection into your data layer — hard to secure, meter, version, or govern — whereas a well-designed API puts a stable, observable contract in front of the same data. ODBC still has a real place inside the trusted boundary, powering BI tools and ETL close to the database, but for anything crossing an organizational or agentic boundary the guidance is consistent: put an API in front of it, not a raw connection.