Databricks is now best understood as a unified data, analytics, and AI platform<\/strong> rather than only a Spark notebook tool. Its current platform brings together data ingestion, data engineering, streaming, SQL warehousing, BI, governance, machine learning, generative AI, model serving, and app building<\/strong> in one environment. The core idea is that teams should not need one tool for ETL, another for warehouse, another for ML, another for governance, and yet another for AI apps; Databricks tries to keep those workflows on a single governed foundation. (Databricks Documentation<\/a>)<\/p>\n\n\n\n At the center of that platform is Unity Catalog<\/strong>, which is Databricks\u2019 built-in governance layer. Unity Catalog gives one place to manage access, organization, lineage, discovery, and governance for tables, volumes, models, features, functions, and more<\/strong> across workspaces. In practice, this means a data engineer, analyst, and ML engineer can work on the same governed assets without each team inventing a separate access model. (Databricks Documentation<\/a>)<\/p>\n\n\n\n For data engineering<\/strong>, Databricks covers both batch and streaming. Its current ingestion and pipeline story is centered on Lakeflow<\/strong>: Lakeflow Connect<\/strong> for ingesting from files, databases, SaaS apps, cloud storage, and message buses, Lakeflow Spark Declarative Pipelines<\/strong> for building batch and streaming pipelines in SQL or Python, and Lakeflow Jobs<\/strong> for orchestration and scheduling. This makes Databricks suitable for building end-to-end pipelines from source ingestion to curated data products. (Databricks Documentation<\/a>)<\/p>\n\n\n\n For analytics and BI<\/strong>, Databricks includes Databricks SQL<\/strong>, SQL warehouses<\/strong>, queries<\/strong>, dashboards<\/strong>, alerts<\/strong>, query history<\/strong>, and natural-language analytics through Genie<\/strong>. Databricks currently recommends serverless SQL warehouses<\/strong> for most SQL workloads when available, and Genie lets business users ask questions about data in plain language instead of writing SQL. Metric Views<\/strong> add a governed semantic layer so teams can define business metrics once and reuse them consistently. (Databricks Documentation<\/a>)<\/p>\n\n\n\n For AI and machine learning<\/strong>, the platform now groups capabilities under Mosaic AI<\/strong>. That includes experiment tracking, model lifecycle, feature management, vector search, agent tooling, and model serving. Databricks also has AI Gateway<\/strong>, which acts as a governance and monitoring control plane for LLM endpoints, coding agents, and serving endpoints. In other words, Databricks is not only for training classic ML models anymore; it is also designed for production GenAI and agentic workloads. (Databricks Documentation<\/a>)<\/p>\n\n\n\n A newer and important part of the story is that Databricks is increasingly becoming a place to build end-user data and AI applications directly on the platform<\/strong>. Databricks Apps<\/strong> lets teams deploy secure data and AI apps on Databricks\u2019 serverless platform, with native integration to Unity Catalog, Databricks SQL, and OAuth. That is useful for internal dashboards, RAG chat apps, forms, and operational tools without managing separate app infrastructure. (Databricks Documentation<\/a>)<\/p>\n\n\n\n What often feels missing on other platforms<\/strong> is not one individual feature, but the combination<\/strong> of features in one governed plane. Databricks is especially strong where you want one control model across data engineering, analytics, AI, and apps<\/strong>. Unity Catalog governing data and AI assets together, Delta Sharing<\/strong> as an open sharing protocol, Clean Rooms<\/strong> for privacy-preserving collaboration, Lakehouse Federation<\/strong> for querying external systems through governed foreign catalogs, and system tables<\/strong> for platform-level billing, access, lineage, and operational analytics are examples of capabilities that many teams otherwise assemble from multiple products. (Databricks Documentation<\/a>)<\/p>\n\n\n\n So, in plain words, Databricks can ingest data, transform it, govern it, query it, visualize it, share it, use it for ML and GenAI, deploy models and agents, and even host the apps built on top of it<\/strong>. That is the clearest overall picture today. Recent platform signals also show where Databricks is heading: Lakeflow<\/strong> has become the umbrella for ingestion\/jobs\/pipelines, Genie Code<\/strong> has expanded agentic capabilities for multi-step data work, and governed tags<\/strong> became generally available in April 2026, which further strengthens governance and discoverability. (Databricks Documentation<\/a>)<\/p>\n\n\n\n Databricks is a unified data and AI platform where teams can ingest, engineer, govern, analyze, share, and operationalize data and AI products from one place.<\/strong> (Databricks Documentation<\/a>)<\/p>\n\n\n\n Below is a simple, human, easy-to-understand Phase 1 terminology guide<\/strong> you can use as your foundation. Databricks\u2019 current sidebar includes areas like Workspace, Catalog, Jobs & Pipelines, Compute, Marketplace, SQL Editor, Queries, Dashboards, Genie, Alerts, Query History, SQL Warehouses, Playground, Agents, Experiments, Features, Models, and Serving<\/strong>. (Databricks Documentation<\/a>)<\/p>\n\n\n\n Think of Databricks like this:<\/p>\n\n\n\n That is very close to how Unity Catalog is structured: catalog \u2192 schema \u2192 table \/ view \/ volume \/ model \/ function<\/strong>, while the workspace<\/strong> is where people create and organize working assets like notebooks, queries, dashboards, and files. (Databricks Documentation<\/a>)<\/p>\n\n\n\n A Catalog<\/strong> is the top business container in Unity Catalog. Simple example:<\/strong> Inside a catalog, you create schemas. Databricks defines a catalog as the first level of the Unity Catalog namespace. (Databricks Documentation<\/a>)<\/p>\n\n\n\n A Metastore<\/strong> is the central registry behind Unity Catalog. Simple understanding:<\/strong> Workspaces<\/strong> means you may have multiple Databricks environments, such as:<\/p>\n\n\n\n A user can switch between workspaces if they have access. Databricks documents workspace switching in the UI and describes workspaces as organizational environments for developing and sharing objects. (Databricks Documentation<\/a>)<\/p>\n\n\n\n A Workspace<\/strong> is one Databricks environment where users actually work. Simple example:<\/strong> A Schema<\/strong> is the second layer inside a catalog. Simple example:<\/strong> So a table might look like: A Table<\/strong> is where your actual rows of data live. Simple example:<\/strong> So in simple words, a table is your real business data stored in a structured form. (Databricks Documentation<\/a>)<\/p>\n\n\n\n A Notebook<\/strong> is an interactive document where you write and run code. Simple example:<\/strong> It is one of the most common working assets in Databricks. (Databricks Documentation<\/a>)<\/p>\n\n\n\n These are the things users usually create in the Workspace<\/strong> area.<\/p>\n\n\n\n A Folder<\/strong> is simply a place to organize workspace objects.<\/p>\n\n\n\n Simple example:<\/strong> Use it to keep notebooks, files, queries, and dashboards neatly arranged. Workspace objects can be organized in the workspace browser. (Databricks Documentation<\/a>)<\/p>\n\n\n\n A Git Folder<\/strong> is Databricks\u2019 integrated Git repository experience. Simple example:<\/strong> A Notebook<\/strong> in workspace-level creation means you are creating a new coding or analysis document inside your workspace. I think your term \u201cFile Query\u201d<\/strong> likely means either File<\/strong> or Query<\/strong>.<\/p>\n\n\n\n Databricks now supports queries, dashboards, and alerts as workspace files<\/strong>, and the SQL editor is used to author and manage queries. (Databricks Documentation<\/a>)<\/p>\n\n\n\n An ETL Pipeline<\/strong> is the flow that moves and transforms data:<\/p>\n\n\n\n In modern Databricks, this is commonly done with Lakeflow Spark Declarative Pipelines<\/strong> or Lakeflow Connect<\/strong>, depending on the use case. (Databricks Documentation<\/a>)<\/p>\n\n\n\n A Dashboard<\/strong> is a visual reporting layer built on top of your queries and metrics.<\/p>\n\n\n\n Simple example:<\/strong> Dashboards are first-class objects in the current workspace UI. (Databricks Documentation<\/a>)<\/p>\n\n\n\n A Genie Space<\/strong> is a no-code chat space where business users can ask questions in natural language about their data.<\/p>\n\n\n\n Simple example:<\/strong> Databricks describes Genie as a natural-language interface for business teams, with space-level curation and organizational terminology. (Databricks Documentation<\/a>)<\/p>\n\n\n\n A Vector Search Index<\/strong> is a searchable AI index built from a Delta table so you can find semantically similar content instead of only exact matches.<\/p>\n\n\n\n Simple example:<\/strong> Databricks says the index is created from a Delta table and can be set to sync automatically when the source table changes. (Databricks Documentation<\/a>)<\/p>\n\n\n\n A Synced Table<\/strong> is a read-only table that automatically synchronizes data from Unity Catalog into a database instance.<\/p>\n\n\n\n Simple understanding:<\/strong> A Metric View<\/strong> is a governed way to define business metrics once and reuse them everywhere.<\/p>\n\n\n\n Simple example:<\/strong> Databricks describes metric views as centralized, reusable, governed business metrics that can be used across dashboards, Genie spaces, and alerts. (Databricks Documentation<\/a>)<\/p>\n\n\n\n These are typically objects you create under the Catalog<\/strong> or Unity Catalog area.<\/p>\n\n\n\n At catalog level, creating a Catalog<\/strong> means creating a top-level governed container for data and AI assets.<\/p>\n\n\n\n Use case:<\/strong> An External Location<\/strong> links a cloud storage path with a credential so Databricks can govern access to that location.<\/p>\n\n\n\n Simple example:<\/strong> Databricks defines an external location as a securable object that combines a storage path with a storage credential. (Databricks Documentation<\/a>)<\/p>\n\n\n\n A Volume<\/strong> is for non-tabular files under Unity Catalog governance.<\/p>\n\n\n\n Simple example:<\/strong> If tables are for rows and columns, volumes are for files and folders. Volumes live in the Unity Catalog namespace as Here, the term usually means Storage Credential<\/strong> in Unity Catalog, and sometimes Service Credential<\/strong> depending on the feature.<\/p>\n\n\n\n Simple example:<\/strong> Databricks documents storage credentials as the credential object used by external locations to access cloud storage. (Databricks Documentation<\/a>)<\/p>\n\n\n\n A Connection<\/strong> is used mainly for Lakehouse Federation<\/strong>.What stands out compared with many other platforms<\/h2>\n\n\n\n
Phase 1: Databricks terminology<\/h1>\n\n\n\n
First, the big picture<\/h2>\n\n\n\n
\n
\n\n\n\nCore terms<\/h2>\n\n\n\n
Catalog<\/h3>\n\n\n\n
It is usually used to separate data by business area, environment, or ownership.<\/p>\n\n\n\n
You may create catalogs like:<\/p>\n\n\n\n\n
sales<\/code><\/li>\n\n\n\nfinance<\/code><\/li>\n\n\n\nmarketing<\/code><\/li>\n\n\n\ndev<\/code><\/li>\n\n\n\nprod<\/code><\/li>\n<\/ul>\n\n\n\nMetastore<\/h3>\n\n\n\n
It stores the structure and metadata of your data objects, such as tables, columns, data types, and where data lives.<\/p>\n\n\n\n
If your company has many workspaces, the metastore is the central brain that keeps governance consistent across them. Unity Catalog uses this centralized model for access control, auditing, lineage, and discovery across workspaces. (Databricks Documentation<\/a>)<\/p>\n\n\n\nWorkspaces<\/h3>\n\n\n\n
\n
Workspace<\/h3>\n\n\n\n
This is where you create notebooks, files, queries, dashboards, experiments, jobs, and other working assets.<\/p>\n\n\n\n
If Unity Catalog is the governed data layer, the Workspace is the place where engineers, analysts, and data scientists do their daily work. (Databricks Documentation<\/a>)<\/p>\n\n\n\nSchema<\/h3>\n\n\n\n
It is a container inside a catalog that holds tables, views, volumes, models, and functions.<\/p>\n\n\n\n
If sales<\/code> is a catalog, then schemas inside it might be:<\/p>\n\n\n\n\n
raw<\/code><\/li>\n\n\n\ncurated<\/code><\/li>\n\n\n\nreporting<\/code><\/li>\n<\/ul>\n\n\n\nsales.reporting.monthly_revenue<\/code> (Databricks Documentation<\/a>)<\/p>\n\n\n\nTable<\/h3>\n\n\n\n
In Databricks, tables created there use Delta Lake by default<\/strong>.<\/p>\n\n\n\n
A customer table may contain:<\/p>\n\n\n\n\n
Notebook<\/h3>\n\n\n\n
You can use Python, SQL, Scala, or R in notebooks.<\/p>\n\n\n\n
You may use one notebook to:<\/p>\n\n\n\n\n
\n\n\n\nWorkspace-level create options<\/h1>\n\n\n\n
Folder<\/h3>\n\n\n\n
You may keep:<\/p>\n\n\n\n\n
\/Shared\/Finance<\/code><\/li>\n\n\n\n\/Users\/rajesh\/tutorials<\/code><\/li>\n\n\n\n\/Projects\/customer360<\/code><\/li>\n<\/ul>\n\n\n\nGit Folder<\/h3>\n\n\n\n
It was formerly called Repos<\/strong>.<\/p>\n\n\n\n
If your team stores notebooks and Python files in GitHub, GitLab, or Azure DevOps, a Git folder lets you clone that repo into Databricks and work with branches, commits, and CI\/CD more cleanly. (Databricks Documentation<\/a>)<\/p>\n\n\n\nNotebook<\/h3>\n\n\n\n
This is where most hands-on tutorials begin. (Databricks Documentation<\/a>)<\/p>\n\n\n\nFile \/ Query<\/h3>\n\n\n\n
\n
.py<\/code>, .sql<\/code>, .yml<\/code>, or config files.<\/li>\n\n\n\nETL Pipeline<\/h3>\n\n\n\n
\n
Dashboard<\/h3>\n\n\n\n
Instead of showing raw SQL results, you show charts like:<\/p>\n\n\n\n\n
Genie Space<\/h3>\n\n\n\n
A business user types:
\u201cShow me last quarter revenue by region\u201d
Genie tries to understand the business language and generate the right answer based on curated data and instructions.<\/p>\n\n\n\nVector Search Index<\/h3>\n\n\n\n
If you have thousands of product descriptions or support documents, vector search helps you find the most relevant ones even when the words are different but the meaning is similar.<\/p>\n\n\n\nSynced Table<\/h3>\n\n\n\n
Use it when you want governed lakehouse data to be made available in another serving-style database system without manually copying data every time. Databricks defines synced tables as read-only synchronized Postgres tables sourced from Unity Catalog tables. (Databricks Documentation<\/a>)<\/p>\n\n\n\nMetric View<\/h3>\n\n\n\n
Instead of every dashboard author writing a different formula for \u201cnet revenue\u201d or \u201cactive customer,\u201d you define it once in a metric view and use the same meaning everywhere.<\/p>\n\n\n\n
\n\n\n\nCatalog-level create options<\/h1>\n\n\n\n
Catalog<\/h3>\n\n\n\n
Create finance<\/code> for finance data, hr<\/code> for HR data, or prod<\/code> for production assets. Databricks supports standard, foreign, and shared catalogs. (Databricks Documentation<\/a>)<\/p>\n\n\n\nExternal Location<\/h3>\n\n\n\n
Your raw files already live in S3.
You create an external location so Databricks can safely use that path under Unity Catalog governance.<\/p>\n\n\n\nVolume<\/h3>\n\n\n\n
Use a volume for:<\/p>\n\n\n\n\n
catalog.schema.volume<\/code>. (Databricks Documentation<\/a>)<\/p>\n\n\n\nCredential<\/h3>\n\n\n\n
A storage credential is the secure identity Databricks uses to access cloud storage.
Instead of giving each user direct S3 access, Databricks uses the credential in a governed way.<\/p>\n\n\n\nConnection<\/h3>\n\n\n\n
It stores the connection details and credentials for an external database or external service.<\/p>\n\n\n\n