Accelerators
The risky parts of a Databricks programme, already solved.
Most Databricks programmes slow down in the same few places. It's the warehouse migration whose scope nobody can prove, the agent that never gets out of the notebook, the model change nobody can score before it ships, or the overnight job that failed without anyone knowing what it cost.
Each tool here takes one of those on, and it's free and open source under Apache-2.0. We built them because we kept solving the same problems by hand. Your team runs them in your own workspace, with our engineers alongside for as long as that helps.
How they fit together.
Platform is how the applications your team builds on Databricks keep an audit trail. Every change those applications make, by a person or an AI agent, has to pass a policy before it happens and is recorded with who made it and why, so when someone asks who changed a record and on whose authority, the answer is a query.
Harness is how your team runs AI agents on your Databricks data safely in production. Each agent can only read what Unity Catalog grants it, stops for a person's approval before the actions that need one, and keeps working through a restart instead of losing the run.
A governed migration factory for moving warehouse and ETL estates to Databricks.
Runway takes the manual steps out of releasing Databricks Apps, for data teams who can build one but can't ship one after another without somebody doing it by hand. Each pull request gets a preview your reviewers can open, an app that fails its evaluation can't be promoted, and you can see who owns every app in the workspace and what it costs.
Governed mission control for running data and ML workloads on Databricks.
Tower is the console your people use to supervise AI agents working on your Databricks data. They see every run, approve anything that would leave the workspace, and can pause or redirect one agent without turning the whole service off.
Experiments is how your data team proves a new model or agent beats the one in production before it ships. It scores every change on your own Databricks data, so you can show the business a number instead of an opinion, and a version that fails its quality gate doesn't reach production.
Which one for which problem
They're listed in the order the work usually happens. An estate arrives on Databricks, agents get built on it, somebody has to judge whether they're any good, they ship, people supervise them, and the workloads underneath get watched. Each line says how far along the accelerator is, in the words of its own repository.
01
The warehouse has to move and nobody can prove what's in scope
Airlift. Console, worker, CLI and Asset Bundle deployment are implemented, with executable playbooks for twenty-seven source platforms including Snowflake, Synapse, Redshift, Oracle, Teradata and SQL Server. Its first two weeks are sold on their own as the Migration Readiness Sprint.
02
The agent demo dies on the first timeout
Harness. Production-grade, with the local runtime, Temporal worker path, model provider registry, approvals and Docker sandbox running real workloads.
03
Nobody can say whether the new version is better
Experiments. Live across a typed API, a CLI, a studio UI, Cloudflare edge workers and Temporal.
04
Databricks Apps ship by hand, or ship regressions
Runway. Templates, delivery pipeline and governance layer are implemented, and a read-only preview is public.
05
Several agents are working and nobody can approve anything
Fabric Tower. Phase one is live with a real squad end to end, and a mission parked at approval has survived a full restart against Temporal Cloud.
06
A job failed overnight and nobody knows what it cost
Radar. Domain module, policies, state machines and projections are implemented, with a Temporal intervention worker and a Databricks effector.
07
Every new product forks the last one
TechFabric Platform. Published on npm as @fabricorg/platform, and the other six are built on it.
Databricks Solution Accelerators, and how ours differ
If you searched for Databricks accelerators, you may have wanted Databricks' own. Those are free notebooks, published by Databricks for any customer, that take one industry use case from idea to proof of concept, and Databricks says that can be as little as two weeks. Forecasting, ESG scoring, a question-answering bot over documents. The code lives in the databricks-industry-solutions organisation on GitHub, which held 232 repositories when we looked.
The seven on this page cover the parts of a programme that aren't a use case. Proving a migration's scope, keeping an agent alive through a deploy, scoring a change before it ships, and recording who approved what. They sit happily together.
Take Databricks' many-model forecasting notebook as the use case, then use Runway to ship it as an app and Experiments to tell you whether this week's model beat last week's. All seven are free and open source under Apache-2.0, and they run in your workspace, not ours.
Checked on 11 October 2026 against Databricks Solution Accelerators and the databricks-industry-solutions GitHub organisation.
What adopting one involves
01
Name the workload
One migration, one agent, one app. An accelerator applied to everything at once is a platform project, and those stall.
02
Read what you already run
Before installing anything we look at the workspace as it is: the catalogues, the service principals, the jobs and who owns them. For a migration that reading is the readiness sprint.
03
Deploy it into your workspace
Airlift and Runway deploy through Databricks Asset Bundles. On Databricks, Harness agents run as Databricks Apps under their own service principal, so what they can read is whatever Unity Catalog grants that principal.
04
Run it on the real work, together
Our engineers run it beside yours on the workload you named, so the first wave or the first agent is a production result rather than a demo of the tool.
05
Hand it over
Your team runs the second one. The code is yours to keep under Apache-2.0, and you can stop working with us without losing any of it.
Worth having ready
- A workspace admin who can create a service principal
- Unity Catalog on for the workspace, since governed tools resolve through it
- The workload you'd start with, and the person who owns its outcome
- Your security team's process for granting a new tool read access
- The engineers who'll run it after we leave, named early
Put them to work on your Databricks programme.
They come with the engineers who built them, which is the part that makes them useful. Tell us what you are trying to move and we will tell you which of these shortens it.