TL;DR

In the past, working with external data in Firebolt — such as External Tables, COPY FROM, COPY TO, and TVFs — meant manually embedding cloud credentials (like AWS keys) into every query or table definition. This was a tedious and risky practice. The new LOCATION object replaces this with a secure, reusable way to store and manage credentials across databases, engines, and operations. It simplifies workflows, strengthens security, and lays the foundation for scalable, future-proof integrations.

The Credential Problem We Had to Solve

Until now, working with external data in Firebolt required manually embedding credentials into every external table, COPY statement, or TVF query.

This approach made life harder for engineers and security teams alike:

• Credentials were duplicated across queries and projects.
  
• Rotation of secrets was complex and error-prone.
  
• It was impossible to separate who can see the credentials from who can use them — creating unnecessary exposure risks.

It was clear that we needed a better model — one that combined security, simplicity, and operational efficiency at scale.

The Breakthrough: Introducing the LOCATION Object

Firebolt’s LOCATION object provides a clean, powerful solution.

A LOCATION is a secure, reusable object that stores:

• Credentials for external access.
  
• Source-specific configuration (such as S3 URLs).
  
• Optional descriptive metadata.
  

Instead of repeating credentials across SQL scripts, users define a LOCATION once — and reference it wherever needed:

COPY INTO my_table
FROM my_data_location
WITH
OBJECT_PATTERN = '*.parquet'
TYPE = PARQUET;

‍

Currently, LOCATION supports AWS S3 as the first storage integration.

But the design is extensible by nature — built to seamlessly support a wide variety of authenticated sources in the future, including:

• Apache Iceberg REST catalogs
  
• Apache Kafka clusters
  
• Google Cloud Storage
  
• Third-party APIs requiring credentials
  

As we extend Firebolt’s language features, we’ll also keep extending LOCATION to integrate with more and more technologies.   So LOCATION is the foundation for how Firebolt will securely and efficiently connect to external systems going forward.

A Closer Look at LOCATION

Centralized, Account-Level Scope

LOCATION objects are created at the account level, not the database level.

This design ensures:

• Easy sharing across multiple databases and engines.
  
• Simplified credential management across teams and environments.
  
• One place to rotate credentials safely, affecting all dependents automatically.

Example: Using a LOCATION across databases

-- While Using Database A: Create a LOCATION object. This isn't tied to the database, but the account.
USE DATABASE a;

CREATE LOCATION shared_data WITH
  SOURCE = 'AMAZON_S3',
  CREDENTIALS = (AWS_ROLE_ARN = 'arn:aws:iam::123456789012:role/S3Access'),
  URL = 's3://cross-db-example/';

-- While Using Database B: Referencing the same LOCATION just works.
USE DATABASE b;

CREATE EXTERNAL TABLE ext_table_b (
  id INT,
  name TEXT
)
LOCATION = shared_data
OBJECT_PATTERN = '*.parquet'
TYPE = PARQUET;

🔐 Even though databases a and b are isolated, they can reference the same LOCATION — enabling secure, centralized access management.

RBAC-Driven Access Control — With Credential Separation

Firebolt extends its RBAC system to LOCATION objects, introducing fine-grained privileges:

• CREATE LOCATION
  
• MODIFY LOCATION
  
• USAGE LOCATION
  

This is not just about permissions — it fundamentally improves credential security:

• Only creators and modifiers of a LOCATION can view or change the credentials.
  
• Users with USAGE privilege can access the external data without ever seeing the credentials themselves.

Example: Restricting LOCATION modification, enabling safe usage

-- Admin creates a secure LOCATION object
CREATE LOCATION secure_loc WITH
  SOURCE = 'AMAZON_S3',
  CREDENTIALS = (AWS_ACCESS_KEY_ID = 'key' AWS_SECRET_ACCESS_KEY = 'secret'),
  URL = 's3://secure-data/';

-- Admin grants only usage rights to analysts
GRANT USAGE ON LOCATION secure_loc TO role_data_analyst;

-- Analysts can query external data:
-- (they don't see credentials and cannot modify the location)
COPY INTO analytics_table
FROM secure_loc
WITH OBJECT_PATTERN = '*.parquet' TYPE = PARQUET;

‍

🧑💼 If an analyst tries to alter the LOCATION:

ALTER LOCATION secure_loc SET URL = 's3://oops/';
-- ERROR: location 'secure_loc' does not exist or not authorized.

‍

🔐 This ensures a clean separation:

• Admins manage credentials.
  
• Users access data — without compromising security.
  

There is now a clear, enforced boundary between the people who manage secrets and the people who use the data.

This separation dramatically strengthens credential hygiene in large organizations, ensuring that only authorized users handle sensitive authentication details.

Administrators can easily grant or restrict access at both object-level and account-level granularity, aligning with security best practices.

Encryption Everywhere

Every LOCATION object:

• Encrypts credentials at rest using Firebolt’s KMS integration.
  
• Caches decrypted credentials securely (for a limited window) to balance performance and security.
  
• Masks sensitive information even in system metadata views.
  

Credentials are never stored or surfaced in plaintext after creation.

Safe Dependency Management

Firebolt makes sure that managing LOCATIONs is safe:

• Locations can’t be dropped if they are still in use by external tables or other objects.
  
• Concurrency between create/alter/drop operations is safely controlled.
  

This ensures strong consistency and safety even in complex environments.

LOCATION in Action: Simplifying Daily Operations

Here’s what changes for users:

‍

External tables, COPY TO/FROM operations, and TVFs are all LOCATION-aware making external access easier, safer, and more scalable across the platform.

Future-Proof Extensibility: Building for Tomorrow’s Needs

SELECT *
FROM read_csv(
  location => my_s3_location,
  object_pattern => 'daily/*.csv',
  header => TRUE
);

‍

Although today LOCATION supports only AWS S3 storage, it is designed to grow into Firebolt’s universal external authentication layer.

Over time, we plan to extend LOCATION support with:

• Apache Iceberg REST-based catalog authentication (for next-generation lakehouses)
  
• Apache Kafka integrations with SASL/SSL credentials
  
• Azure Blob Storage and Google Cloud Storage secure access
  
• Any third-party APIs that require token, key, or role-based authentication
  

RBAC, encryption, dependency management, and system integration are ready to scale with new source types.

By investing early in LOCATION’s flexibility, Firebolt ensures that connecting to new data sources — no matter how diverse — will always remain secure, simple, and efficient.

Conclusion: A Foundation for Simpler, Safer, Scalable Access

Managing credentials in Firebolt has just become a lot simpler.

The LOCATION object is a foundational improvement to Firebolt’s data access model. It removes the friction of embedding secrets in every query, enables clean separation of duties through RBAC, and allows credentials to be managed centrally and reused safely across your entire account — from external tables to COPY statements and TVFs.

It’s a small change to how you write SQL — but a big leap in how Firebolt handles external access.

And as support grows for new source types like Iceberg, Kafka, and cloud object stores, LOCATION will make those connections seamless, secure, and easy to use.

We’re excited about where this takes us — and even more excited to see what you build with it.