snowflake-connector-python: the DB API 2.0 driver now superseded by universal core

The repository now points you somewhere else

The first thing in the README is a notice, and it changes the framing of everything else in the page.

Version 5.0.0 of the Snowflake Connector for Python has been released. Development has moved to the snowflakedb/drivers repository, and the README points at the documentation for the universal core for more information.

So this repository is where the 4.x line lives and where the transition is recorded, not where new connector work happens. That is the single most important fact for anyone evaluating it, and it is the kind of notice that is easy to miss when you arrive at a project from a search result and start reading the feature list.

The released versions here are recent and the project is not abandoned in any practical sense. v4.8.0 was published on 2026-09-30, v4.7.5 on 2026-09-21 and v4.7.4 on 2026-09-16, and the last push was on 2026-10-15. The licence is Apache-2.0, and the primary language is Python.

What the connector is, in the README's own terms: this package includes the Snowflake Connector for Python, which conforms to the Python DB API 2.0 specification. It provides an interface for developing Python applications that can connect to Snowflake and perform all standard operations, and it provides a programming alternative to developing applications in Java or C/C++ using the Snowflake JDBC or ODBC drivers.

That last clause is the design decision. Most database clients for Python are either thin wrappers over a C library or a driver with a compiled dependency. This one is pure Python and has no dependencies on JDBC or ODBC, and it can be installed with pip on Linux, Mac OSX and Windows where Python 3.10.0 or higher is installed.

Building a wheel locally, and the Docker path for version matrices

The build instructions are for people who need a specific wheel rather than the published one, and they come in two forms.

Locally, you install a supported Python version, clone the repository, and run these commands to create a wheel package using the PEP-517 build:

git clone [email protected]:snowflakedb/snowflake-connector-python.git
cd snowflake-connector-python
python -m pip install -U pip setuptools wheel build
python -m build --wheel .

The resulting `snowflake_connector_python*.whl` package is found in the `./dist` directory.

In Docker, the project provides a Dockerized build script, `ci/build_docker.sh`, and the built wheel files are found in `dist/repaired_wheels`. The script can also compile only certain versions, which matters when you are producing a wheel for one interpreter rather than the whole matrix:

The pyproject.toml shows how the wheels are produced and it contains a few decisions worth knowing about. The build requirements are `setuptools>=40.6.0`, `wheel` and `cython>=3.1`, the last with a comment explaining that it is required for the `freethreading_compatible` directive used in the nanoarrow Arrow iterator source. The cibuildwheel configuration pins the manylinux image to `manylinux2014` and sets the auditwheel environment variable to match.

The free-threaded builds are opt-in. The configuration notes that without `enable = ["cpython-freethreading"]`, cibuildwheel silently skips every `cp*t-*` target even when the matrix and the CIBW_BUILD environment variable ask for them, and that this requires cibuildwheel 2.20 or newer. It is paired with the Cython directive so that the produced wheel actually keeps the GIL disabled at import time.

The architecture coverage is broad. Linux builds for x86_64 and aarch64, macOS for x86_64 and arm64, and Windows for AMD64 only. The Linux and macOS sections set `repair-wheel-command = ""` to exclude pre-built minicore libraries from auditwheel repair, and the macOS note says not to repair macOS wheels.

A Rust mini core inside a Python driver, and what setup.py does about it

The notes at the end of the README mention the piece that explains most of the build complexity. The driver uses a Rust library called sf_mini_core, and its source is in the snowflakedb/universal-driver repository under the sf_mini_core path.

So this is a pure Python driver in the sense that it needs no JDBC or ODBC, but it carries a compiled component, and the packaging has to arrange for that component to be present and correctly linked on each platform. The cibuildwheel configuration is where that shows: pre-built minicore libraries are deliberately excluded from wheel repair, and the check-manifest configuration lists the minicore source directory under ignore-bad-ideas.

The setup.py file shows the same story in code. It imports the Cython build tooling inside a try block, and if the import fails it emits a warning that it cannot compile native C code because of a missing build dependency, and sets a flag saying extensions cannot be compiled. The flag is what makes the rest of the build tolerant of a missing Cython.

Two environment variables gate that behaviour. `SNOWFLAKE_DISABLE_COMPILE_ARROW_EXTENSIONS`, with the positive values y, yes, t, true, 1 and on, controls whether the native Arrow extensions are compiled. `SNOWFLAKE_NO_BOTO` does the same for the boto dependency. Both are read from the environment at setup time, and the positive value list is defined once in the file and reused for both.

The version handling is worth a note too. The setup file has a default VERSION tuple of (1, 1, 1, None), and it then tries to execute `generated_version.py` from the connector source directory, falling back to `version.py` if that fails. The version is assembled by joining the tuple's parts with dots, skipping the None. In other words, the released version is not in setup.py at all, it is generated during the build, and the fallback file carries the value used when generation has not run.

The source layout is `src/snowflake/connector/`, with the Arrow iterator living under a `nanoarrow_cpp/ArrowIterator` subdirectory that holds the .pyx file the Cython directive applies to.

Log secret masking that reaches into third party loggers

The log secret masking section describes a default behaviour that is broader than the connector's own logging, and it is a good example of a security default that costs something.

By default, the connector masks secrets, which the README lists as tokens, passwords, cloud credentials and private keys, in records emitted by the `snowflake.connector` loggers and by the third-party loggers it uses. Those third parties are named: `botocore`, `boto3`, `aiohttp`, `aiobotocore`, `aioboto3`, and a vendored `urllib3`.

The scope of that is the part to understand. Masking applies even when logging is configured with `logging.basicConfig`, not only when Easy Logging, which is enabled with `save_logs = true` in `config.toml`, is turned on. And the same opt-out covers those third-party trees: they also interpolate the message and clear `record.args`.

The mechanism is stated plainly. The masker interpolates each log record and clears `record.args`. The README recommends leaving masking enabled unless you need the escape hatch.

The escape hatch is an environment variable, `SNOWFLAKE_DISABLE_LOG_SECRET_MASKING`, set to `true`. The connector reads it on every log record, which makes it usable as an escape hatch if masking is incompatible with a log pipeline, for example one that depends on structured `record.args`. Setting it before importing `snowflake.connector` also skips installing the masking hook:

export SNOWFLAKE_DISABLE_LOG_SECRET_MASKING=true

That second part is the practically important detail. Because the hook is installed at import time, exporting the variable afterwards does not prevent the hook from being installed, it only changes what the hook does. Anyone using this escape hatch with a structured logging pipeline needs it in the environment before the process starts.

The reason clearing `record.args` matters is that a formatted message with the secret interpolated is safe to log, while the raw `record.args` tuple still holds the secret in memory and would be rendered by any formatter that uses it. Clearing it removes the second copy.

Telemetry off, in two different places

Telemetry is on by default, and the connector gives you two ways to turn it off, one of which is a session parameter and one of which is a property on the connection object.

By default, the Snowflake Connector for Python collects telemetry data to improve the product. The first way to disable it is to set the session parameter `CLIENT_TELEMETRY_ENABLED` to `False` when connecting:

import snowflake.connector
conn = snowflake.connector.connect(
    user='XXXX',
    password='XXXX',
    account='XXXX',
    session_parameters={
      "CLIENT_TELEMETRY_ENABLED": False,
    }
)

The second is to set the `telemetry_enabled` property to `False` on the `SnowflakeConnection` object:

import snowflake.connector
conn = snowflake.connector.connect(
    user='XXXX',
    password='XXXX',
    account='XXXX',
)
conn.telemetry_enabled = False

The difference between them is when they take effect. The session parameter is part of the connect call, so it applies to the session from the start. The property is set after the connection exists, which means the handshake that created the session has already happened.

The repository layout gives the supporting picture. There is a `prober/` directory, which is the natural home for the code that measures and reports, a `benchmark/` directory, a `test/` directory, `tested_requirements/`, and a `samples/` directory with a README and an example called `auth_by_key_pair_from_file.py`, which suggests key pair authentication is a supported path with a worked example.

The tooling for contributors is worth noting as well. The code hygiene utilities are integrated into tox so they can be set up on any computer. `fix_lint` runs pre-commit to check for a range of lint issues and can be installed to run on every local commit. `coverage` runs coverage.py to combine generated coverage data files into an overall file when several categories were run. `flake8` is marked deprecated, and is similar to fix_lint but only runs flake8 checks.

Package signatures with cosign, and the one endpoint gap

Two things in the closing sections matter for anyone running this in a controlled environment.

The first is signature verification. To ensure the authenticity and integrity of the Python package, the README gives steps to verify the package signature using cosign. You install cosign, download the file from the repository like pypi, download the signature files from the release tag replacing the version number with the version you are verifying, and then verify the signature. The command in the documentation is:

  ./cosign verify-blob snowflake_connector_python-3.12.2.tar.gz \
  --key snowflake-connector-python-v3.12.2.pub \
  --signature resources.linux.snowflake_connector_python-3.12.2.tar.gz.sig

and the expected output is a Verified OK line. The version numbers in the example are 3.12.2, and the key and signature file names follow the same version, so each release needs its own key and signature pulled from the release tag.

The second is a functional gap that the README states plainly. The library currently does not support GCP regional endpoints, and it asks that any workloads using this library do not require support for regional endpoints on GCP, directing questions to Snowflake Support.

That is a narrow but hard limitation. Regional endpoints on GCP let a session be pinned to a specific region, and a workload that needs that cannot use this library as it stands.

The other note in the same section is the one from the opening, and it is about where this is going rather than what it does. The driver uses the Rust library called sf_mini_core, whose source is in the snowflakedb/universal-driver repository. The same repository, the one that took development over from version 5.0.0, is where the Rust component lives. So the Python connector in this repository and the universal core driver are two views of the same underlying client, and the direction of travel is toward the second.

Editorial conclusion

Adopt snowflake-connector-python if you are maintaining an existing deployment or need the current 4.x line with its Python-native Arrow extensions, and install it with pip on Python 3.10 or newer. Do not start new work on this repository, because the README states that version 5.0.0 has been released and development has moved to snowflakedb/drivers, and check first that your workloads do not depend on GCP regional endpoints, which the driver does not support.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. snowflakedb/snowflake-connector-python on GitHub