LOCATION objects
Learn about LOCATION objects in Firebolt for secure, centralized credential management.
LOCATION objects are secure, reusable objects that store connection details and credentials for external data sources. Instead of embedding credentials directly into every query or table definition, you can create a LOCATION object once and reference it wherever needed across your Firebolt account.
What are LOCATION objects?
A LOCATION object is a foundational improvement to Firebolt’s data access model that centralizes credential management and strengthens security. Each LOCATION object stores:
- Credentials for external access (AWS keys, roles, OAuth tokens)
- Source-specific configuration such as S3 URLs, REST endpoints
- Optional descriptive metadata for documentation and organization
LOCATION objects eliminate the need to repeatedly specify credentials across SQL scripts, making your data workflows more secure, maintainable, and scalable.
The problem LOCATION objects solve
Before LOCATION objects, working with external data in Firebolt required manually embedding credentials into every external table, COPY statement, or table-valued function (TVF) query. This approach created several challenges:
- Credential duplication: The same credentials had to be copied across multiple queries and projects
- Complex secret rotation: Updating credentials required finding and modifying every occurrence
- Security exposure: It was impossible to separate who can see credentials from who can use them
- Error-prone maintenance: Manual credential management led to inconsistencies and mistakes
How LOCATION objects work
LOCATION objects operate at the account level. This design provides several advantages:
- Cross-database sharing: Use the same LOCATION across multiple databases and engines
- Centralized management: Update credentials in one place to affect all dependent objects
- Team collaboration: Share secure access to external data sources across your organization
Example
For more information about working with external tables, see Working with external tables.
Security and access control
LOCATION objects solve a critical security challenge that wasn’t possible with embedded credentials: protecting sensitive access information. Before locations, credentials had to be embedded directly in external tables, COPY statements, or TVF queries, making it impossible to control who could see or use them. With locations, you can:
- Protect credentials: Store sensitive access information in a secure object that can be managed through RBAC
- Control access: Grant USAGE permission to roles that need to access the data without exposing the credentials
- Separate concerns: Allow administrators to manage credentials while data users can only use them
For detailed information about location permissions, see Location permissions.
Example: Secure credential management
For more information about setting up roles and granting permissions, see Role-Based Access Control (RBAC).
Using LOCATION objects
LOCATION objects work seamlessly with all Firebolt features that access external data:
External tables
Replace inline credentials with a LOCATION reference:
For more information about using locations in external tables, see CREATE EXTERNAL TABLE.
COPY operations
Simplify data loading and exporting:
For more information, see COPY FROM and COPY TO.
Table-valued functions (TVFs)
Access external data directly in queries:
For more information about table-valued functions, see READ_CSV, READ_PARQUET, READ_ICEBERG, and LIST_OBJECTS.
Supported data sources
LOCATION objects currently support multiple data source types:
Amazon S3
For S3-based data storage with AWS authentication:
For more details about S3 LOCATION objects, see CREATE LOCATION (Amazon S3).
Apache Iceberg
For data lake architectures with Iceberg tables:
For more details about Iceberg LOCATION objects, see CREATE LOCATION (Iceberg).
Best practices
1. Use descriptive names and documentation
2. Follow the principle of least privilege
Grant only the minimum required permissions:
3. Organize by environment and purpose
4. Regular credential rotation
Establish a process for rotating credentials:
5. Monitor and audit usage
Use the information schema to track LOCATION usage:
For more information about the locations information schema, see information_schema.locations.
Querying location metadata
Checking location dependencies
Before dropping a LOCATION object, you can check which objects depend on it:
Permissions
LOCATION
objects are managed using RBAC with the following permission levels. For detailed information about location permissions, see Location permissions.
Privilege | Applicable On | Description | GRANT Syntax | REVOKE Syntax |
---|---|---|---|---|
MODIFY | Location | Allows editing specific location objects. | GRANT MODIFY ON LOCATION <location_name> TO <role>; | REVOKE MODIFY ON LOCATION <location_name> FROM <role>; |
USAGE | Location | Allows using specific location objects without seeing credentials. | GRANT USAGE ON LOCATION <location_name> TO <role>; | REVOKE USAGE ON LOCATION <location_name> FROM <role>; |
CREATE LOCATION | Account | Allows creating new location objects in the account. | GRANT CREATE LOCATION ON ACCOUNT <account_name> TO <role>; | REVOKE CREATE LOCATION ON ACCOUNT <account_name> FROM <role>; |
MODIFY ANY LOCATION | Account | Allows editing all current and future locations in the account. | GRANT MODIFY ANY LOCATION ON ACCOUNT <account_name> TO <role>; | REVOKE MODIFY ANY LOCATION ON ACCOUNT <account_name> FROM <role>; |
USAGE ANY LOCATION | Account | Allows using all current and future locations in the account. | GRANT USAGE ANY LOCATION ON ACCOUNT <account_name> TO <role>; | REVOKE USAGE ANY LOCATION ON ACCOUNT <account_name> FROM <role>; |
For more information about location permissions, see Location permissions.
Required permissions
To view location information, you must have one of the following privileges:
MODIFY
- Modify locations you have access toUSAGE
- Use locations you have access to
For more details about the available columns and examples, see information_schema.locations.
Important: External tables that reference a LOCATION object become invalid and inaccessible if the LOCATION is dropped. Check for dependent external tables before removing a LOCATION, or they will need to be manually dropped after the LOCATION removal. For complete dependency management guidance, see DROP LOCATION.
Managing LOCATION objects
Creating LOCATION objects
Use CREATE LOCATION to create new LOCATION objects:
For complete syntax and all options, see CREATE LOCATION.
Modifying LOCATION objects
Use ALTER LOCATION to update existing objects:
For complete syntax and options, see ALTER LOCATION.
Dropping LOCATION objects
Use DROP LOCATION to remove objects:
For complete syntax and safety considerations, see DROP LOCATION.
Related documentation
Security and access control
- Role-Based Access Control (RBAC) - Understanding RBAC permissions for LOCATION objects
- Location permissions - Detailed information about location permissions
- information_schema.locations - Querying LOCATION metadata and dependencies
Commands and operations
- CREATE LOCATION - Complete syntax and examples
- ALTER LOCATION - Modifying existing LOCATION objects
- DROP LOCATION - Safely removing LOCATION objects
Data access with LOCATION objects
- CREATE EXTERNAL TABLE - Using LOCATION with external tables
- COPY FROM - Loading data with LOCATION objects
- COPY TO - Exporting data with LOCATION objects
- Table-valued functions - Direct data access with LOCATION objects