Skip to main content
Creates a new location object in your Firebolt account, which is a secure, reusable object that stores the connection details and credentials for external data sources. Instead of entering these details each time you run a query or create a table, you can use a location object. The location object stores the following:
  • The source type specification
  • Authentication credentials
  • The data source URL
  • Optional descriptive metadata
This makes it easier to manage data access, keeps your credentials safe, and saves you from having to repeat the same information across multiple queries. You can use LOCATION to centralize credential storage with managed access with Role-Based Access Control (RBAC) for CREATE, MODIFY, and USAGE permissions for different users, use a single location definition for multiple tables and queries, and control access to sensitive data. LOCATION is version control-friendly because no sensitive credentials are stored in source code. After you create a LOCATION, you can use the information_schema.locations view to see details about all the locations in your account including source type, URL, description, owner and creation time. For a comprehensive guide to understanding and using LOCATION objects, see LOCATION objects. Related: This document covers LOCATION objects in general. For more information about specific types of LOCATION objects, including more in-depth examples, please see:

Syntax

When you authenticate with AWS_ROLE_ARN, set the optional AWS_ROLE_EXTERNAL_ID to add a customer-controlled condition to your role’s trust policy.
For role-based AWS access you can additionally set an external ID. An external ID is a value you choose and control that AWS checks when Firebolt assumes your role, adding a second condition on top of your account’s unique IAM principal. Configuring one is a recommended best practice. See IAM roles.

Parameters

Common Parameters

Cloud Storage Parameters

Amazon S3 Parameters

Amazon Bedrock Parameters

Iceberg Parameters

AWS Authentication Parameters

OAuth Authentication Parameters

Iceberg Catalog-Specific Parameters

FILE_BASED Catalog
REST Catalog
DATABRICKS_UNITY Catalog
SNOWFLAKE_OPEN_CATALOG Catalog
Snowflake Open Catalog is a REST-shaped catalog and takes the same parameters as REST. See CREATE LOCATION (Iceberg) for details.
AWS_GLUE Catalog

Examples

Create a location

The following code example creates a location that uses keys to authenticate to AWS:

Create a location with a description

The following code example creates a location object named my_location, for an Amazon S3 data source with the specified URL and description:

Create a location only if it doesn’t exist

The following code example uses an access key to authenticate to AWS using a location only if it doesn’t already exist:

Use a location to load data into an external table

The following code example creates an external table my_ext_table that uses a previously created location my_location to load Parquet data files matching the *.parquet pattern from Amazon S3:
For more information about using locations in external tables, see CREATE EXTERNAL TABLE.

Use a location to load data using COPY statements

The following code example uses COPY FROM to load Parquet data files matching the *.parquet pattern from my_location into my_table:
For more information, see COPY TO and COPY FROM.

Use a LOCATION to load data with a TVF

You can use LOCATION to load data using table-valued functions (TVFs) such as READ_CSV, READ_PARQUET, and LIST_OBJECTS. The following code example uses READ_CSV to query data from a CSV file stored in my_location, using the first row as headers for column names:

Alter a location

Firebolt does not yet support altering a location that has been created. This feature will be available in a future release.

Delete a location

You can use DROP LOCATION to remove a location from your Firebolt account. The following code example deletes a LOCATION from your Firbolt account:
Deleting a location will affect all objects that depend on the LOCATION that you are dropping.

Notes

  • All identifiers are case-insensitive unless enclosed in double-quotes
  • For more information about object identifiers, see Object identifiers

Error Handling

The system uses secure error handling for location objects:
  • Generic error messages ensure security by not exposing sensitive information.
  • Detailed error information is only available to users with the necessary permissions.
  • Users without the required permissions are provided with instructions to contact an administrator.

Best Practices

  1. Use location objects instead of embedding credentials directly in queries or table definitions.
  2. Regularly rotate credentials stored in location objects.
  3. Follow the principle of least privilege when assigning permissions.
  4. Use clear and descriptive names and descriptions for location objects.
  5. Keep a record of dependencies before removing any location objects.

Limitations

  • The DROP CASCADE functionality is not supported.
  • The source type cannot be modified for existing location objects.
  • Location objects cannot be used alongside inline credentials in the same statement.
  • Historical versions of credentials are not maintained.