You're on Firebolt: It Serves Your Customers' Analytics in Milliseconds. Data Workers Owns Whether Those Answers Are Right
Firebolt serves low-latency analytics to customer-facing apps, on the managed service or Firebolt Core. Data Workers traces a wrong number in a customer dashboard to its source and gets the fix approved.
Your product team runs Firebolt because customers will not wait for a dashboard. The app sends thousands of small queries at once and each one comes back in milliseconds: an engine sized for the load, a fact table with primary indexes, and aggregating indexes that Firebolt maintains "in the same transaction that writes the base table, so a query never sees a stale result". The SQL is PostgreSQL-compatible, dbt models build through the dbt-firebolt adapter, and since release 4.32 an Iceberg catalog on AWS Glue, a REST catalog, Snowflake Open Catalog or Databricks Unity attaches as a database with CREATE ICEBERG DATABASE. Teams run the managed service, generally available on AWS and GCP with Azure in preview, or Firebolt Core, the free self-hosted edition, as a single binary, a Helm chart or a Kubernetes operator; Firebolt's homepage now presents the engine as open source, with that release in preview.
Firebolt is the fastest path from a table to a customer's screen. Whether the table holds the right numbers is a different job. A payments service moves new card payments to a new table, a nightly export keeps reading the old one, and the portfolio dashboard thousands of customers open every morning reports rent as unpaid while every query succeeds. Data Workers watches the data behind your customer-facing tables, traces a wrong number to its cause and gets the fix approved before a customer acts on it.
Key takeaways
- •Firebolt keeps its job. Engines, databases, indexes, the app's queries and access roles stay with your product and platform teams. Data Workers works on the data those queries read and on the changes that move it.
- •Connected from day one. Data Workers connects to Firebolt over its API or MCP server today and reads the systems around it natively: PostgreSQL, dbt, Dagster, Airflow, Slack and GitHub.
- •Wrong numbers, traced to the source. When an upstream change leaves a customer-facing table wrong, Data Workers raises one incident with the cause, the blast radius and the fix proposed.
- •Every fix goes through a named person. The owner approves the change and merges it; Data Workers queues the approved rerun and checks the result.
- •Autonomy is set per domain. Start at L1 observe, move to L2 propose, and open L3 act reversibly for narrow classes once the record supports it.
Firebolt is the low-latency engine your customers query. Data Workers is the operator that keeps their answers right.
One week at a property-management software company (an illustration, not a customer case).
The company sells software to apartment operators. Residents pay rent through its payments service, which writes to the payments.transactions table in Postgres. Every night a Dagster job, rent_ledger_refresh, runs an asset that exports the day's rows from that table to an Iceberg table registered in AWS Glue and emits OpenLineage events to Marquez. The same job then runs dbt with the dbt-firebolt adapter: Firebolt reads the Iceberg table through an attached Iceberg database, and dbt builds fct_rent_ledger and rpt_delinquency as Firebolt tables, with an aggregating index on rent collected by community and day. The operator app's Portfolio Insights dashboards query Firebolt directly, and a late-notice batch reads rpt_delinquency every Friday at 09:00 of rent week. The dbt project declares both as exposures, and the team has recorded both in the context graph. Rent is due Tuesday, September 1.
| Time | System | What happens |
|---|---|---|
| Mon Aug 31 15:40 | Postgres | The payments team releases a new card processor path to 23% of communities. Its payments land in a new table, payments.card_transactions, with the same columns; the old path keeps writing payments.transactions. The split is a planned step in their migration |
| Tue Sep 1 | Payments service | Rent day. Every payment settles correctly, in one table or the other |
| Wed 01:00 | Dagster + AWS Glue | The export asset reads payments.transactions as it always has and writes Tuesday's partition to the Iceberg table. The 41,000 rent-day payments on the new path are not in it |
| Wed 01:30 | Dagster + dbt + Firebolt | dbt rebuilds fct_rent_ledger and rpt_delinquency in Firebolt. Residents whose payments never arrived read as unpaid. The not_null and unique tests on transaction_id pass. Firebolt updates the aggregating index in the same transaction, exactly as designed |
| Wed 06:00 | Data Workers | Rent collected on the first two days of the month, a metric the team records with monitor_metrics, reads 21% under its baseline. Data Workers opens an incident |
| Wed 06:07 | Data Workers + Postgres | Data Workers reads the payments schema from Postgres natively and finds card_transactions: about 41,000 rows and no reader anywhere in the lineage graph. diagnose_incident ranks it first. trace_cross_platform_lineage follows the table through the team's note on the export to the Iceberg table and the dbt models, and blast_radius_analysis returns the two recorded readers: Portfolio Insights and Friday's late-notice batch |
| Wed 06:20 | Claude Code + Firebolt MCP | The on-call analytics engineer asks in Claude Code. Her client calls Firebolt's own MCP server under a service account with a read-only role, and a query confirms 41,000 residents marked unpaid for September 1, all in communities on the new processor path |
| Wed 06:30 | Data Workers + Slack | Data Workers proposes two diffs for the owners to merge: have the export read both payment tables into the Iceberg table, with a processor column, and add a dbt test that fails when a community with active leases shows no payments on rent day. The approval request goes to the analytics engineering lead who owns the models, with the data platform owner on the export change. The finding recommends that the product team hold Friday's batch until the fix verifies |
| Wed 08:15 | Spellbook + GitHub | The owners review the diffs, blast radius and rollback (revert both commits and rerun), approve and merge |
| Wed 08:20 | Data Workers + Dagster | Data Workers queues the approved rent_ledger_refresh run with trigger_dagster_job, configured by the owner to re-export August 31 through September 1. Dagster finishes it at 08:52 and the new test passes |
| Wed 09:10 | Data Workers | Rent collected is back on baseline and the delinquency count is back in its usual range. The receipt records the cause, the approvals, the run, the checks and the undo |
| Fri 09:00 | Operator app | The late-notice batch runs on the corrected list. No resident who paid gets a late notice |
Postgres stored what the service wrote, the export copied the table it was told to copy, dbt's tests checked what they were written to check, and Firebolt served every query fast and consistent with its tables. Catching it took knowledge outside any one engine: a payments table split, an export did not know, and a Friday batch reads the result.
| Job | What Firebolt does | What Data Workers does |
|---|---|---|
| The query | Serves high-concurrency SQL in milliseconds from engines you size, on the managed service or Firebolt Core | Connects to Firebolt over its API or MCP server and reads the sources, models and jobs around it |
| The meaning | Holds table, index and Iceberg catalog metadata for its databases | Keeps one governed context graph from each source table through the export and dbt to every customer-facing reader the team records |
| The checks | Enforces declared types and keeps aggregating indexes consistent; dbt tests run against it | Holds key metrics to a baseline and ties a jump to the schema change or release behind it |
| The fix | Runs whatever SQL, model build or role change the owner chooses | Proposes the change as a diff to a named owner, then queues the approved run through Dagster or Airflow; dbt Cloud reruns go to the owner after approval |
| The proof | Keeps query history and engine metrics | Re-checks the data and writes a receipt: what changed, who approved it, how it was checked, how to undo it |
Why doesn't Firebolt just do this itself?
Because Firebolt is an engine by design, and that focus is why product teams put it in front of customers: it answers every query fast and keeps its own tables and indexes consistent in the same transaction. Whether a payments service started writing somewhere new is a question about the sources upstream, which an engine rightly leaves to their owners.
Firebolt's AI follows the same scope. Firebolt Agent in the Workspace answers questions about Firebolt, generates SQL from your schema and fixes invalid queries; Firebolt's docs say "the agent does not access your data", and users review the generated SQL before running it. AI_QUERY calls a model from SQL. Firebolt's MCP server connects an LLM client to your databases and documentation and runs SQL within whatever the service account's role allows, which is why a read-only role is the sensible setting for production. Sound choices for an engine serving customers.
Owning whether the data is right from a Postgres source through an export, an Iceberg table and dbt to a customer's screen is a different product: a context graph across every system, blast-radius scoping, named approvers, a recorded undo and receipts an auditor can read. That is Data Workers. See is it safe to let AI agents change production data.
Every tool owns a slice. Data Workers covers the whole lifecycle
Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, on the Firebolt estate already there.
| Stage | Data Workers | Firebolt | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 3 | Firebolt holds table and index metadata for its own databases and attaches Iceberg catalogs. Data Workers keeps one governed context graph from the source table through dbt to the dashboard your customers open. |
| Analytics & Insights | 8 | 9 | Firebolt's home stage: sub-second SQL at high concurrency, aggregating indexes kept consistent in the same transaction, a PostgreSQL dialect and vector search. Data Workers answers from governed definitions with lineage behind every number. |
| Data Quality | 8 | 3 | Firebolt enforces the constraints and types you declare; tests live in dbt. Data Workers holds key metrics to a baseline and ties a jump to the change that caused it. |
| Observability & Incidents | 8.5 | 4 | Query history and engine metrics show how the engine is running. Data Workers diagnoses the data incident from the source change to the customer-facing table, proposes the fix and verifies it. |
| Pipelines & Ingestion | 8.5 | 6 | COPY from object storage, a Kafka sink connector, Iceberg catalogs and dbt-firebolt load and model data. Data Workers plans the repair and queues the reruns through Dagster or Airflow after approval; dbt Cloud reruns go to the owner. |
| Schema & Migration | 8 | 4 | Iceberg schema evolution is read, with documented limits on type promotion. Data Workers catches a schema change in the dbt manifest or in review, sizes it downstream and plans larger moves in approved waves. |
| Governance & Access | 8.5 | 5 | Role-based access, service accounts and per-engine permissions decide who can query what. Data Workers routes every data change to a named approver and records the decision. |
| Security & Privacy | 8 | 6 | Encryption, network policies and SSO protect the managed service; Core runs inside your own network. Data Workers leaves a receipt on every data change. |
| Cost / FinOps | 8 | 6 | Engines start, stop and scale on their own, and engine size sets the hourly price. Data Workers attributes Snowflake credits to dbt models, totals BigQuery spend and reads AWS Cost Explorer. |
| MLOps & Models | 7.5 | 4 | AI_QUERY and AI_EMBED_TEXT call a model from SQL and vector indexes serve retrieval. Data Workers keeps the data under models and agents healthy. |
How Firebolt and Data Workers work together
Data Workers connects to Firebolt over its API or MCP server today. Firebolt stays the place where customer queries run, indexes live and access roles are set.
Most of what sits under and around Firebolt connects natively: PostgreSQL, Snowflake and BigQuery as sources; dbt and dbt Cloud, Dagster, Airflow, Prefect and Step Functions; Tableau and Looker (read), Datadog (read), GitHub (pull-request review) and Slack, among 50+ connectors. The Iceberg catalog Firebolt attaches, on AWS Glue or a REST catalog, stays the team's inventory of lake tables and connects over its API or MCP server today; Data Workers follows those tables through the dbt manifest and the team's context-graph notes.
Firebolt's MCP server belongs in the same client as Data Workers'. The team's client calls it for queries and Firebolt documentation; Data Workers' agents work from their own connectors. By design, Firebolt engines, databases, indexes and roles stay with the owner; Data Workers proposes changes, scopes what they touch and verifies afterwards.
Setup follows the documented client setup: clone the open-source repo and add each agent's start-agent.sh entry to your client. Add Firebolt's MCP server per its README, with a service account whose role can only read, or with your Core URL for Firebolt Core.
# Example: Data Workers agents in Claude Code, from a clone of the open-source repo
claude mcp add --scope user dw-incidents -- "$(pwd)/start-agent.sh" dw-incidents
claude mcp add --scope user dw-catalog -- "$(pwd)/start-agent.sh" dw-context-catalog
claude mcp add --scope user dw-connectors -- "$(pwd)/start-agent.sh" dw-connectors
# Firebolt's MCP server, per its README (Docker image; service account with a read-only role)
claude mcp add firebolt \
-e FIREBOLT_MCP_CLIENT_ID="$FIREBOLT_CLIENT_ID" \
-e FIREBOLT_MCP_CLIENT_SECRET="$FIREBOLT_CLIENT_SECRET" \
-- docker run -i --rm -e FIREBOLT_MCP_CLIENT_ID -e FIREBOLT_MCP_CLIENT_SECRET \
ghcr.io/firebolt-db/mcp-server:latest
# For Firebolt Core, pass FIREBOLT_MCP_CORE_URL (for example http://localhost:3473) insteadList the tools with your client's own command (/mcp in Claude Code). In this incident: monitor_metrics and diagnose_incident (dw-incidents) flag the drop and rank the cause; trace_cross_platform_lineage and blast_radius_analysis (dw-context-catalog) map what reads the table; trigger_dagster_job (dw-connectors) queues the approved run.
The agents run in your infrastructure with your credentials and model key; your data stays in your systems and the hosted Conductor sees workflow metadata only. See where does our data go.
One incident, L0 to L4, set per domain:
- •L0 manual. Friday's batch sends late notices to residents who paid, and support learns about it from operators.
- •L1 observe. Data Workers flags the drop at 06:00 with Monday's new table as the cause and both readers named. Nothing changes.
- •L2 propose. Data Workers proposes the export and model fixes as diffs; nothing changes until the named owners approve.
- •L3 act reversibly. For a class with a clean record, Data Workers queues the approved Dagster run in the domain you open.
- •L4 autonomous. Once the owners' fixes are merged, Data Workers queues the refresh, re-checks the metric and posts the receipt. Firebolt engines, indexes and roles stay with the owner at every level.
Who sets those levels: who owns the agents, how approvals work for AI data agents and autonomy levels L0 to L4 explained.
What changes for your team
- •One record for every team. The product, platform and analytics engineers see the same incident and receipt in Spellbook Data Catalog (in preview), linked from Slack.
- •Customer-facing tables get a guard on their sources. Their key metrics are checked after every nightly build, and a drop is traced through lineage to the source behind it.
- •Customer-facing jobs run after the checks. Teams schedule the batches that email, bill or flag customers after Data Workers' nightly checks, and the incident names any batch at risk before it runs.
For guardrails on agent access to a warehouse, see read-only warehouse access for LLM agents and connecting AI agents to a data warehouse over MCP.
Keep Firebolt, or consolidate?
Keep Firebolt if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For almost every Firebolt team the answer is keep it: low latency at high concurrency is why it was bought. What teams consolidate is the tooling around the data: a separate observability tool, spreadsheets of which customer dashboard reads which table, and runbooks that say "rerun the job and spot-check the portal". Related stacks: you're on ClickHouse, you're on Postgres, you're on MotherDuck and DuckDB, you're on Dagster and Data Workers integrations.
Weighing a build on Firebolt's MCP server and a coding agent? Read build it ourselves with Claude Code and MCP servers.
The case for your CFO
The outcome. When an upstream change leaves a customer-facing number wrong, the error is caught within hours and corrected before customers act on it, with a record of how it was checked. Wrong numbers in a product mean support tickets, credits and churn risk.
The risk story. At L1 agents only read. At L2 a named person approves every change; an unanswered request expires and escalates, never auto-grants. At L3 they act on reversible changes inside the domains you open. Firebolt engines, indexes and roles stay with your team. No agent can promote its own work, an org-wide stop halts all autonomous dispatch, and every change carries a receipt.
Why now. Customer-facing analytics, MCP clients and AI agents now read the same tables, so a wrong number travels further and faster than an internal report ever did.
The first win. L1 on the tables behind your most-used customer dashboards: each one's key metrics checked against baseline after every nightly build.
What stays the same. Firebolt, your engines, the app's queries, dbt, Dagster and your sources. Zero migration. For the numbers, see the ROI of agentic data operations.
The sentence for upstairs: "Firebolt makes our product's analytics fast; Data Workers makes sure the numbers our customers see are right, and gets them fixed with our approval when they aren't."
Getting started
Start with a pilot. Pick the customer-facing tables your product depends on, connect their sources, dbt project and orchestrator, record the metrics that define "right", and run at L1 through a few weeks of releases. Then turn on L2 for one domain. The pilot path is on the pricing page, and the pilot is credited in full against the first year.
FAQ
How does Data Workers connect to Firebolt? Over Firebolt's API or MCP server today. The Postgres sources, dbt project, orchestrator and Slack around it connect natively.
Is Firebolt open source, and does Data Workers work with Firebolt Core? Firebolt Core is the free self-hosted edition of the engine, published on GitHub under the Elastic License 2.0, with v5.0 pre-release builds through September 2026. Firebolt's homepage now presents the engine as open source, in preview. Data Workers works the same way with Core and the managed service: it reads the systems around the engine natively, and your team's assistant reaches Firebolt over its MCP server, which accepts a Core URL in place of service account credentials.
Does Firebolt have an MCP server? Yes. Firebolt's MCP server (Apache 2.0, v0.6.0 released January 26, 2026) connects an LLM client to Firebolt databases and documentation and runs SQL with a service account's permissions. Give it a read-only role for production and add it to the same client as Data Workers, whose agents work from their own connectors.
Our dbt tests passed and Firebolt's indexes were consistent. How was the number wrong? A test checks what it is written to check, such as a unique, non-empty ID, and an index faithfully reflects its table. Rows that never arrive pass both. Data Workers holds key metrics to a baseline and ties a drop to the source change behind it; a rent-day volume test closes the gap.
Will Data Workers change our Firebolt engines, tables or roles? No. Engines, databases, indexes and roles stay with the owner. Data Workers proposes fixes where they live, such as a dbt model or an export config diff, and queues the approved run.
How do Firebolt's Iceberg databases fit in? Since 4.32 Firebolt attaches Iceberg catalogs, including AWS Glue and REST catalogs, as databases it reads (writes are export only). The catalog stays your inventory of lake tables and connects to Data Workers over its API or MCP server today; Data Workers tracks the jobs that write those tables and the dbt models that read them through the dbt manifest and the team's context-graph notes, so the Iceberg tables carry owners and lineage in the same context graph.
Sources
- •Firebolt homepage (managed service GA on AWS and GCP, Azure preview; "open source analytical database (OSS available in preview today)"; single binary, Helm chart, Kubernetes operator; changelog 4.28 to 4.32; pricing and free credits), https://www.firebolt.io/ (checked Oct 3, 2026)
- •Firebolt Core repository (README: "a free, self-hosted edition of Firebolt's high-performance distributed query engine"; LICENSE.md Elastic License 2.0; v5.0.0 pre-release builds Sep 7 to Sep 28, 2026), https://github.com/firebolt-db/firebolt-core (checked Oct 3, 2026)
- •Firebolt docs, self-managed Helm chart, https://docs.firebolt.io/self-managed/helm-chart/overview (checked Oct 3, 2026)
- •Firebolt release notes (4.32: Iceberg catalog databases via CREATE ICEBERG DATABASE over file-based and REST-shaped catalogs incl. AWS Glue, Snowflake Open Catalog and Databricks; LIST_ICEBERG_FILES), https://docs.firebolt.io/release-notes (checked Oct 3, 2026)
- •Firebolt docs, Iceberg (supported catalogs; "Writes: Export only"; schema evolution limits), https://docs.firebolt.io/guides/iceberg-and-data-lake/iceberg (checked Oct 3, 2026)
- •Firebolt docs, Aggregating index ("maintained in the same transaction that writes the base table"), https://docs.firebolt.io/performance-and-observability/storage-and-indexing/aggregating-index (checked Oct 3, 2026)
- •Firebolt docs, Firebolt Agent ("The agent does not access your data"; SQL generation, Fix with AI), https://docs.firebolt.io/guides/ai/firebolt-agent (checked Oct 3, 2026)
- •Firebolt docs, AI_QUERY (Amazon Bedrock; daily token budget), https://docs.firebolt.io/reference-sql/functions-reference/ai/ai-query (checked Oct 3, 2026)
- •Firebolt docs, MCP integration, https://docs.firebolt.io/guides/integrations/mcp (checked Oct 3, 2026)
- •Firebolt MCP server repository (README configuration for the managed service and Core; v0.6.0, Jan 26, 2026), https://github.com/firebolt-db/mcp-server (checked Oct 3, 2026)
- •dbt-firebolt adapter, https://github.com/firebolt-db/dbt-firebolt (checked Oct 3, 2026)
- •Data Workers open-source repository (tool registrations in dw-incidents, dw-schema, dw-context-catalog, dw-connectors), https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)
- •Data Workers client setup guide, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)