- The source type specification
- Authentication credentials
- The data source URL
- Optional descriptive metadata
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:
- CREATE LOCATION (Amazon S3)
- CREATE LOCATION (Amazon Bedrock)
- CREATE LOCATION (Iceberg)
- CREATE LOCATION (Postgres)
- CREATE LOCATION (MongoDB)
Syntax
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 aREST-shaped catalog and takes the same parameters as REST. See CREATE LOCATION (Iceberg) for details.
AWS_GLUE Catalog
Examples
- Create a location
- Create a location with a description
- Create a location only if it doesn’t exist
- Use a location to load data into an external table
- Use a location to load data using COPY statements
- Use a location to load data with a TVF
- Alter a location
- Delete a location
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 namedmy_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 tablemy_ext_table that uses a previously created location my_location to load Parquet data files matching the *.parquet pattern from Amazon S3:
Use a location to load data using COPY statements
The following code example usesCOPY FROM to load Parquet data files matching the *.parquet pattern from my_location into my_table:
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 aLOCATION 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
- Use location objects instead of embedding credentials directly in queries or table definitions.
- Regularly rotate credentials stored in location objects.
- Follow the principle of least privilege when assigning permissions.
- Use clear and descriptive names and descriptions for location objects.
- Keep a record of dependencies before removing any location objects.
Limitations
- The
DROP CASCADEfunctionality 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.