How we write this guide
The Databricks Field Guide is written by TechFabric's engineers. AI assists the drafting, and a TechFabric engineer reviews every page before it is published.
Who writes it
TechFabric is a software and data engineering company in Gilbert, Arizona, and a Databricks partner, with 80 Databricks-certified engineers in a team of more than 115. We migrate warehouses onto Databricks, design Unity Catalog governance, and build the applications, dashboards and agents that run inside the workspace. The guide is what we'd tell a team starting that work.
Chapters are bylined to TechFabric because several engineers contribute to each one. Margin notes carry the name of one engineer. Where a chapter tells a story as our own, it comes from work an engineer has already published or presented, and it links that source:
- Preetham Reddy, CEO and founder: the Lakebase application built live at the first Gilbert Databricks User Group, and the six-week Synapse migration.
- Andrey Taran, Senior Databricks Engineer: embedded analytics on Databricks.
- Ivan Vydrin, Databricks Engineer: Prove It, the Genie app Databricks named a winner of its Genie-Powered App Challenge.
- Ihor Seleznov, Engineer: PyTest checks on the bronze-to-silver promotion.
- Sushruth Aeluguri, Databricks Engineer: Unity Catalog for AI agents, row filters and agent identity worked through on a FHIR lakehouse design.
How a page is made, and where AI comes in
We use AI models to help draft and revise pages: to turn our own notes, talks and posts into a first draft, to check a draft against the documentation it cites, and to point out where it is unclear. AI does not decide what the guide recommends, and it is not a source of experience. A TechFabric engineer reads every new page and every rewrite before it goes live. Small automated updates, such as a feature's release stage moving from Preview to GA, are checked against Databricks' own page and can go live before a person reads them; an engineer reviews them afterwards.
Where a page says "we saw", "we built" or "we migrated", the work really happened and is already public: a post on techfabric.com, a talk at one of our events, or an engineer's own repository. We keep those stories in one register and the build fails a page that claims experience without linking one. Everything else is written as what we'd do, and says so.
How we check facts
- A product fact links the Databricks documentation page it comes from, usually on docs.databricks.com, or Microsoft's for Azure Databricks. Where it depends on a runtime version, a release stage (Beta, Public Preview, GA or legacy) or a date, the page says which.
- Before a page is published, automated checks read it: a fact-check against the sources it cites, the experience register above, a check that every diagram renders and every internal link resolves, and a check for writing that only restates the docs.
- Each page shows the date it last changed in substance. A layout change does not move it.
- This is not Databricks' documentation. Where we and the docs disagree about what the product does today, the docs are right and we want to know.
Corrections
When something here is wrong, we fix the page and move its date. We don't leave the old version standing beside the new one. If a correction changes what we recommend, the page says so in the paragraph that changed.
To report an error, use the contact form with the page and the sentence. We reply when the fix is live.
What TechFabric sells
The guide is free, with no sign-up. TechFabric is paid for engineering work on Databricks,
and where a chapter covers something we are hired for, the box at its end names the
service and links it. The guide is also available as
llms.txt, as Markdown for every chapter, and as a read-only
MCP server at
https://databricks.techfabric.com/mcp.