# Data Source Reference

> Authentication options and data type mappings for every data source supported by the Data Contract CLI.

# Data Source Reference

Lookup material for every supported data source: all **authentication** options (environment variables) and how **data types** are mapped when importing a contract and checked when testing one. For task-oriented walkthroughs, see [Connect your Data](../connect/index.md).

## How authentication works

Connection details (host, catalog, location, …) live in the contract's `servers` block; credentials are provided as environment variables. Variables are also loaded from a `.env` file in the current working directory (or the nearest parent directory containing one); already-set environment variables take precedence.

## How data types work

A contract property carries up to two type declarations:

- **`logicalType`** — one of nine portable ODCS types: `string`, `integer`, `number`, `boolean`, `date`, `timestamp`, `time`, `object`, `array`.
- **`physicalType`** — free text for the native type in the data source (e.g. `VARCHAR(255)`, `NUMBER(38,0)`). It is not validated by `datacontract lint`; at test time it is interpreted in the SQL dialect of the server under test.

When you run `datacontract test`, type checks work in one of two modes:

1. **Native type check** (`Check that field x has physical type y`) — on sources with catalog introspection (Snowflake, BigQuery, Databricks, Postgres, Redshift, SQL Server, Oracle, Trino, Athena), the declared `physicalType` is compared against the actual column type from the catalog. Timezone variants of timestamps are interchangeable; length/precision is only enforced when the contract declares it (`varchar` matches `varchar(255)`, but `varchar(255)` does not match `varchar(100)`). A `physicalType` that can't be interpreted in the server's dialect degrades to the logical check or a warning — never a hard failure.
2. **Logical type check** (`Check that field x has type y`) — everywhere else (and as fallback), both the declared and the actual type are normalized to one of the nine ODCS categories and compared. `integer` and `number` are mutually compatible; a bare `object` or `array` matches any structure with the same base.

For file sources with `format: csv`, `json`, or `avro`, no type checks are generated — the file is read *as* the contract's types, and violations surface as read errors (plus JSON Schema validation for `format: json`).

Independent of the type checks, `logicalTypeOptions` (`minimum`, `maximum`, `minLength`, `maxLength`, `pattern`, `enum`, …) generate value checks that behave identically on every source.

## Data sources

  
    
    SnowflakeAuthentication and data types
  
  
    
    Google BigQueryAuthentication and data types
  
  
    
    DatabricksAuthentication and data types
  
  
    
    PostgresAuthentication and data types
  
  
    
    Amazon S3Authentication and data types
  
  
    
    Local filesData types for CSV, JSON, Parquet, Delta
  
  
    
    Amazon AthenaAuthentication and data types
  
  
    
    Amazon RedshiftAuthentication and data types
  
  
    
    Apache ImpalaAuthentication and data types
  
  
    
    Azure Blob / ADLSAuthentication and data types
  
  
    
    Google Cloud StorageAuthentication and data types
  
  
    
    HTTP APIAuthentication and data types
  
  
    
    KafkaAuthentication and data types
  
  
    
    Microsoft SQL ServerAuthentication and data types
  
  
    
    MySQLAuthentication and data types
  
  
    
    OracleAuthentication and data types
  
  
    
    Spark DataFrameData types for in-memory DataFrames
  
  
    
    TrinoAuthentication and data types