Query Azure Blob Storage from Teradata
Overview
This guide explains how to query data stored in Azure Blob Storage directly from Teradata using Native Object Store (NOS) — no ETL pipeline or data movement required. You will learn how to explore the schema of an object store dataset, query it with standard SQL, and optionally load it into Teradata for repeated use.
About Teradata NOS
Native Object Store (NOS) is a Teradata capability that lets you query data stored in external object stores — such as Azure Blob Storage, Azure Data Lake Storage Gen2, AWS S3, and Google Cloud Storage — using standard Teradata SQL. NOS supports CSV, JSON, and Parquet formats.
NOS is enabled out of the box on all Teradata editions from Teradata Express through TeradataCloud Lake, starting from version 17.10.
For full NOS documentation see the Teradata NOS Getting Started Guide.
Prerequisites
- A Teradata instance.
If you need a test instance of Teradata, you can provision one for free at https://www.teradata.com/try
- An Azure Blob Storage container with data. For private containers you will need a Storage Account Name and either an Access Key or SAS Token.
Location String Format
NOS uses the /az/ prefix for Azure Blob Storage locations. The format is:
For Azure Data Lake Storage Gen2 (ADLS Gen2), the same format applies as long as the URL includes .blob. — both storage types are functionally identical from a NOS perspective.
Step 1: Configure Access
Public containers
For publicly accessible containers, no authorization object is needed. You can query directly using READ_NOS or a foreign table without any credentials. An empty authorization object (see below), might be needed on some Teradata editions.
Private containers
For private containers, create an AUTHORIZATION object with your storage account credentials:
Step 2: Explore the Schema
Before querying data, use RETURNTYPE ('NOSREAD_SCHEMA') to inspect the column names and types inferred from the Parquet files:
To list the files at a given location, use RETURNTYPE ('NOSREAD_KEYS'):
Step 3: Query Data with READ_NOS
To read actual rows, omit the RETURNTYPE clause entirely. NOS will return the data directly.
The example below queries the publicly available Azure Open Datasets NYC Taxi dataset — no Azure account or credentials required:
Scoping the LOCATION path to a specific partition (e.g. puYear=2016/puMonth=6/) significantly reduces the data NOS needs to scan. Always filter by partition columns in the path rather than in the WHERE clause when possible.
For private containers, add the AUTHORIZATION clause:
Step 4: Create a Foreign Table (Optional)
For repeated queries against the same dataset, a foreign table definition avoids repeating the READ_NOS clause every time and makes the data feel like a native Teradata table:
Foreign tables are always created as No Primary Index (NoPI) tables. Each query against a foreign table fetches data live from the object store — NOS does not cache results automatically.
Step 5: Load Data into Teradata (Optional)
If you expect to query the same dataset repeatedly, loading it into Teradata avoids repeated object store reads and potential egress charges. Use CREATE TABLE AS ... WITH DATA:
About Azure Open Datasets
Microsoft hosts several public datasets on azureopendatastorage.blob.core.windows.net with anonymous read access — no Azure account needed. These are useful for testing NOS connectivity or exploring data before building a pipeline.
| Dataset | Location Path |
|---|---|
| NYC Yellow Taxi | /az/azureopendatastorage.blob.core.windows.net/nyctlc/yellow/ |
| NYC Green Taxi | /az/azureopendatastorage.blob.core.windows.net/nyctlc/green/ |
| Public Holidays | /az/azureopendatastorage.blob.core.windows.net/holidaydatacontainer/Processed/ |
| ISD Weather | /az/azureopendatastorage.blob.core.windows.net/isdweatherdatacontainer/ISDWeather/ |
All datasets are stored in Parquet format and partitioned by year and month where applicable.
Data shared via Azure Data Share lands in an Azure Blob Storage container on the consumer side. Once received, it can be queried from Teradata using NOS in exactly the same way as any other Blob Storage dataset — simply point the LOCATION clause at the container where the share was delivered and provide the appropriate AUTHORIZATION object.