Snowflake Drivers, Connectors & Storage/API/Git Integrations

Micro-Concept 1: A Driver Connects One Programming Language

A driver is a client library you install in your application. It opens a session to Snowflake and runs SQL from your code. The driver is the bridge between one language and the Snowflake service.

Snowflake ships drivers for seven environments. The set is JDBC, ODBC, Python, Node.js, Go, .NET, and PHP. Every Snowflake driver uses TLS to secure the connection.

Two distinctions show up on the exam. JDBC and ODBC are standards-based. JDBC serves Java applications and many BI tools. ODBC serves C-based and SQL client tools. The Python connector implements the Python Database API and pairs well with libraries like pandas.

The word to hold is single. A driver connects from one runtime. It does not move a whole data platform into Snowflake. That job belongs to a connector, which is the next concept.

Micro-Concept 2: A Connector Integrates a Whole Ecosystem

A connector wires an external data system into Snowflake. It is broader than a driver. It carries data between a platform and Snowflake, with logic built for that platform.

The Spark connector is the first to know. It makes Snowflake a Spark data source for bi-directional read and write. It also pushes filters and query logic down into Snowflake, so Snowflake does the heavy work. This is the predicate and query pushdown the exam likes to name.

The Kafka connector is the second. It reads records from one or more Apache Kafka topics and loads them into Snowflake tables. It runs inside a Kafka Connect cluster.

One Kafka detail is worth a sentence on its own. The Snowflake Connector for Kafka can use Snowpipe Streaming to write rows directly into tables. This path skips staged files and gives lower latency than file-based loading. It is the row-based loading idea from Day 32, packaged inside the connector.

Hold the line this way. A driver connects from a language. A connector integrates a platform such as Spark or Kafka. A stem that calls Spark or Kafka a driver is wrong on the category.

Micro-Concept 3: A Storage Integration Keeps Credentials Out of the Stage

A storage integration is an account-level object. It stores a generated cloud identity for your external storage, plus a list of allowed and blocked locations. Its purpose is to let a stage reach cloud storage without embedding access keys in the stage definition.

The type is fixed for this use. You create it with TYPE = EXTERNAL_STAGE. A cloud administrator then grants that generated identity permission on the bucket or container. One storage integration can back many external stages.

The exam point is the credential question. Without an integration, a stage may carry raw keys in its DDL, where anyone with view rights can read them. With an integration, the stage names the integration and holds no secrets. This is the same external stage idea from earlier this week, now made credential-free.

Two facts round out the topic. Only the ACCOUNTADMIN role, or a role with the global CREATE INTEGRATION privilege, can create one. After creation you run DESCRIBE INTEGRATION to read the cloud identity Snowflake generated, then you trust that identity on the cloud side.

-- Storage integration: the stage holds no keys
CREATE STORAGE INTEGRATION s3_int
  TYPE = EXTERNAL_STAGE
  STORAGE_PROVIDER = 'S3'
  ENABLED = TRUE
  STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::001234567890:role/myrole'
  STORAGE_ALLOWED_LOCATIONS = ('s3://my-bucket/path/');

-- The stage references the integration, not credentials
CREATE STAGE my_ext_stage
  STORAGE_INTEGRATION = s3_int
  URL = 's3://my-bucket/path/';

Micro-Concept 4: An API Integration Trusts an HTTPS Endpoint

An API integration is a different trust object. It grants Snowflake trusted access to an external HTTPS endpoint. It names the allowed URL prefixes and the provider type.

Two exam uses sit on this object. An external function needs an API integration to call a proxy service such as Amazon API Gateway. The provider is set with API_PROVIDER = aws_api_gateway, or the Azure and Google equivalents. The external function runs on the cloud provider’s compute, not on a Snowflake virtual warehouse.

The second use is Git, covered in the next concept. A Git repository needs an API integration with API_PROVIDER = git_https_api.

Keep the two integrations apart. A storage integration trusts cloud storage for stages. An API integration trusts an HTTPS endpoint for external functions and Git. In training sessions I have run, the swap between these two is the single most common integration mistake.

Micro-Concept 5: Git Integration Brings Version Control Into Snowflake

A Git repository object connects a remote Git repo to your account. It is new to the COF-C03 exam, so expect at least a recognition question on it.

The setup chains two objects. First you create an API integration with API_PROVIDER = git_https_api. Then you create the repository with CREATE GIT REPOSITORY, naming that integration, the origin URL, and an optional credentials secret.

The result is a clone inside Snowflake. It holds every branch, tag, and commit from the remote repo. You reference its files the way you reference a stage path: @my_repo/branches/main/file.sql.

The payoff is running version-controlled code in place. EXECUTE IMMEDIATE FROM runs a SQL file straight from the repository clone. You can also point a stored procedure or function handler at a Python file in the clone. The one fact to carry: Git integration relies on an API integration, never a storage integration.

-- 1. API integration for the Git provider
CREATE API INTEGRATION git_api_int
  API_PROVIDER = git_https_api
  API_ALLOWED_PREFIXES = ('https://github.com/my-account/')
  ENABLED = TRUE;

-- 2. The repository clone references that integration
CREATE GIT REPOSITORY my_repo
  API_INTEGRATION = git_api_int
  ORIGIN = 'https://github.com/my-account/my-repo.git';

-- 3. Run a SQL file straight from the clone
EXECUTE IMMEDIATE FROM @my_repo/branches/main/setup/create_tables.sql;

Authoritative references for every fact in today’s post. The drivers overview and the storage integration reference are the two worth re-reading the day before the exam.

The CREATE API INTEGRATION reference lists every provider value, including the Git and external-function gateways. The Kafka connector guide covers the Snowpipe Streaming path.