Skip to main content

​
Disclaimer: Non-binding Technical Overview

This document provides technical specifications regarding data portability, export mechanisms, and interoperability for the Firebolt platform. It is intended to support the switching requirements under the EU Data Act.For legal terms, mandatory notice periods, and commercial conditions, please refer to the Firebolt Data Act Amendment in your specific customer contract.

​
1. Service scope and data categories

Firebolt is a cloud data warehouse and analytics platform that stores and processes customer data on decoupled compute and storage, using compressed columnar storage and indexing for performance. For the purpose of the EU Data Act, we group data handled by Firebolt into:
  1. Customer data in managed tables: Structured and semi-structured data that you ingest into Firebolt-managed tables from data lakes, relational databases and other sources.
  2. External data referenced by Firebolt: Data that remains in your own storage (typically Amazon S3 or lake formats) and is only referenced via external tables. Firebolt stores metadata only, not the source files.
  3. Metadata and configuration:
    • Databases, schemas, tables, indexes, engines
    • Roles and permissions
    • System views in information_schema that describe objects and usage
  4. Query results: Results of SQL queries run against managed or external data. These can be exported directly to Amazon S3 in common formats.
  5. Observability and operational data:
  6. Firebolt internal assets: Internal algorithms, optimizers, cache contents, storage layout and other proprietary system internals. These are not part of exportable customer data.

​
2. Data ingestion — sources and formats

​
2.1 Managed table ingestion

Customers can ingest data into Firebolt-managed tables using:

​
2.2 External tables and lake access

  • External tables act as connectors to external data sources, usually files in S3.
    • Firebolt stores only metadata, not the source data itself.
    • External tables are used to query formats such as Parquet and other lake formats without loading into managed storage.
  • Additional table-valued functions (such as READ_CSV, READ_AVRO, READ_PARQUET, and READ_ICEBERG) extend this to open file and table formats.

​
3. Data export — mechanisms and formats

​
3.1 Export via COPY TO

Firebolt provides the COPY TO SQL command which exports the results of any SELECT query to Amazon S3 in a specified file format. Supported file formats include:
  • CSV, TSV, JSON, and Parquet

​
3.2 Export from the Workspace UI

In addition to the above methods, the Firebolt console allows you to export query results by copying them to the clipboard or downloading them as a file. These ad-hoc exports are suitable for smaller query results, for example to be consumed by downstream tools or spreadsheets. For full scale data export and vendor switching, customers should use the COPY TO command.

​
4. What can be exported, by data category

​
4.1 Managed table data

Exportable All rows and columns in managed tables can be retrieved with SELECT and exported using COPY TO in CSV, TSV, JSON, or Parquet formats. Example: 
COPY (SELECT * FROM db.schema.table_name)
TO 's3://your-bucket/firebolt-exports/table_name/'
WITH (FORMAT = 'PARQUET');
This produces standard files in S3 that can be loaded into other data warehouses or lake engines.

​
4.2 External table data

Exportable, but stored outside Firebolt
  • External tables do not store data in Firebolt. They store pointers and processing parameters for files in your own S3 buckets.
Customers already control those source files and can:
  • Continue using them directly outside Firebolt, or
  • Use Firebolt to export query results over external data via COPY TO if they want a transformed or filtered snapshot.

​
4.3 Semi-structured and nested data

Semi-structured data in Parquet, Avro, JSON Lines, etc can be loaded to Firebolt via COPY TO or queried through external tables. It remains exportable in either:
  • Relational form (flattened through SQL SELECT), or
  • Semi-structured form using COPY TO with JSON or Parquet format.

​
4.4 Metadata and configuration

The Firebolt information_schema provides system views containing:
  • Tables, indexes, columns and constraints
  • Engines and their state
  • Roles, grants and other account level metadata
These views are queryable with SQL SELECT and so are exportable through COPY TO: This lets customers reconstruct schemas and configurations in another system or in their own environment.

​
4.5 Observability and operational data

Firebolt exposes several information_schema views for observability:
  • engine_query_history
    • Contains metadata about executed queries
    • Retains only the most recent 10,000 queries per engine cluster
  • engine_user_query_history
    • Filters engine_query_history to queries initiated by human users
    • Machine-generated queries remain in engine_query_history and form a complete audit log
  • engine_running_queries
    • Shows information about queries currently running in a database
  • engine_metrics_history
    • Resource usage metrics such as CPU, RAM, disk, cache and spilling
    • Per default, snapshots are collected roughly every 30 seconds and retained for 30 days.
  • engine_metering_history
    • Records engine consumption in FBUs over time, which can be used for cost and capacity analysis.
All of these views can be queried and exported via COPY TO, so observability data that is still within its retention window is exportable. Additionally:
  • Firebolt integrates with OpenTelemetry and provides an OpenTelemetry exporter so that customers can stream telemetry data into their own monitoring stack, independent of Firebolt.

​
4.6 Firebolt internal assets and non-exportable items

The following are not considered exportable customer data:
  • Internal algorithms, query optimizer logic, cost models and execution engine internals.
  • Details of internal storage layout and cache content beyond what is surfaced in metrics and explain plans.
  • Ephemeral runtime state that is not exposed through documented views or APIs.
Where internal telemetry is exposed (for example via the telemetry JSON column in engine_query_history), that portion is exportable in the same way as other observability data.

​
5. Limitations and retention characteristics

In line with the EU Data Act requirement to disclose limitations, Firebolt has the following relevant technical limits in the public documentation:
  • engine_query_history retains only the last 10,000 queries per engine cluster. Older entries are dropped.
  • engine_metrics_history collects roughly 2 snapshots per minute and keeps data for 30 days. Metrics older than this are not available for export.
  • engine_running_queries shows active queries only, up to 10,000 entries per engine cluster.
  • For data accessed via external tables, Firebolt holds only metadata. The customer remains responsible for lifecycle and retention of the underlying files in S3 or other storage.
Customers who need longer retention for observability data can:
  • periodically export system views using COPY TO, or
  • use the OpenTelemetry exporter to store telemetry in their own observability platforms.

​
6. Switching to another provider or on premises environment

The EU Data Act requires that customers can switch providers without undue technical or commercial obstacles.

​
6.1 Data export for switching

Customers can:
  1. Export all required data and derived datasets via COPY TO using open formats to their own S3 buckets.
  2. Export metadata and schema information from information_schema views to reconstruct table and index structures in the target system.
  3. Export observability and consumption data to understand usage patterns and size target capacity.
  4. Use existing lake files that were already in S3 and referenced through external tables, which remain under customer control outside of Firebolt.

​
6.2 Import into target systems

Firebolt export formats are broadly compatible with common data warehouses and lakes. Migration to another system typically involves:
  • Creating equivalent schemas in the target.
  • Loading exported CSV or Parquet files into the target database tables.
  • Optionally, replaying business logic using preserved query history and other metadata.

​
6.3 Permissions and controls

Export operations and access to observability data are governed by Firebolt role based access control: Customers can limit who is allowed to initiate large scale export or migration.