presto-python-client

presto-python-client is the official Python client for Presto, the distributed SQL query engine for querying large datasets across heterogeneous sources. It implements the PEP 249 DB-API 2.0 specification, so it plugs into any Python tool that expects a standard connect()/cursor()/execute() interface, while also exposing a lower-level PrestoRequest/PrestoQuery API for direct control over the HTTP protocol Presto’s coordinator speaks.

Beyond basic query execution, the client supports pluggable authentication (Kerberos, HTTP Basic, and OAuth-style service-account flows for GCP), session properties, catalogs and schemas, and transaction isolation levels, making it suitable for both ad-hoc scripting and production data pipelines that need to talk to a Presto cluster over LDAP- or Kerberos-secured networks.

What You Get

• A PEP 249 DB-API 2.0 connect()/Cursor interface that works with existing Python SQL tooling
• A lower-level PrestoRequest/PrestoQuery API for direct control over the HTTP protocol
• Pluggable authentication backends for Kerberos, HTTP Basic, and OAuth/service-account flows
• Transaction isolation-level support built on Presto’s session and transaction headers

Common Use Cases

• Querying Presto from Python ETL and analytics scripts
• Powering SQLAlchemy-style tooling and BI connectors that expect a DB-API driver
• Connecting to Kerberos- or LDAP-secured Presto clusters from automated jobs
• Running ad-hoc SQL against system.runtime tables for cluster introspection and monitoring

Under The Hood

Architecture The prestodb package is organized into small, single-purpose modules: client.py implements the HTTP protocol layer (ClientSession, PrestoRequest, and PrestoQuery manage the POST-then-poll-nextUri cycle against a Presto coordinator), dbapi.py wraps that layer in a PEP 249-compliant Connection/Cursor surface, auth.py defines an abstract Authentication base class with Kerberos/Basic/OAuth strategy subclasses injected into the shared requests.Session, transaction.py holds the IsolationLevel enum and Transaction bookkeeping, redirect.py handles gateway-redirect following, and exceptions.py defines the DB-API exception hierarchy. The layering is clean (dbapi depends on client, auth is injected via constructor rather than inheritance) but tightly coupled: both dbapi.py and any custom Authentication subclass reach directly into client.py’s ClientSession and PrestoRequest, so changes to that module’s constructor signature ripple everywhere.

Tech Stack A pure Python 2.7/3.5-3.9 library (per setup.py classifiers, though clearly dated given the project’s low recent activity) with only three required dependencies: click, requests, and six; optional extras add requests_kerberos for Kerberos auth and google_auth for GCP service-account flows. Packaging is classic setuptools (setup.py, setup.cfg) with no pyproject.toml or modern build backend. Testing runs on pytest with httpretty for HTTP response mocking, tox drives multi-version test matrices, and CI is a legacy Travis config that spins up a Dockerized Presto server for integration tests.

Code Quality Unit tests exist for the client, exceptions, and HTTP layers (tests/test_client.py, test_exceptions.py, test_http.py), using httpretty to mock coordinator responses and including doctest-style usage examples in module docstrings. Error handling is structured through a typed exception hierarchy in exceptions.py rather than swallowed. Type hints appear inconsistently, mixing PEP 484 comment-style annotations with plain untyped signatures, and there is no visible linter or formatter configuration in the repo. CI still runs on Travis rather than a modern pipeline, consistent with the project’s low commit velocity.

API Design DB-API 2.0 compliance is the project’s central design choice: because Cursor exposes execute()/fetchone()/fetchmany()/fetchall(), the client works out of the box with generic Python SQL tooling (pandas.read_sql, SQLAlchemy-style dialects) without any Presto-specific glue code. A pluggable Authentication strategy class gives a clean extension point for new auth schemes without touching client internals, and a single dbapi.connect(host, port, user, catalog, schema) call is enough to get a working connection. Small inconsistencies remain, such as differently-named handle_err/handle_error methods across Authentication subclasses, but the overall surface favors minimal boilerplate over novelty.