Databricks Data Science

Name: Databricks Data Science
Brand: Databricks
Rating: 4.6 (1032 reviews)

Databricks Data Science is the data science and machine learning capability within the Databricks Lakehouse platform that provides collaborative notebooks, distributed Spark compute (including GPU options), ML lifecycle tooling and model operationalization on governed cloud data.

Est 2013|Valuation $188B|Raised $33.1B

LinkedIn 1.3M|Website|Web traffic 4.3M|FTEs 16,133|HQ San Francisco, California, US

MarketsData Warehouses & Lakehouses Data Science & Machine Learning Platforms Machine Learning Ops (MLOps)

Published May 16, 2026

01Common complaints

Small teams with light workloads: Spark cluster startup/operational overhead can dominate; simpler tools may be cheaper and faster.
Organizations needing very predictable, simple billing: DBU + cloud infra split can be challenging without strong FinOps.
Analytics-only organizations (mostly BI, high concurrency, governance-first): A warehouse-first platform (Snowflake/BigQuery) may be a more suitable primary home.
Strict policies against serverless or compute outside the customer’s cloud account: some managed features may be restricted under such policies.
Organizations that prefer to avoid notebook-centric workflows: Some practitioners report notebook-centric experiences; if an organization requires pure IDE/GitOps workflows, validate fit carefully.

Based on recurring community and review signals (not exhaustive):

Documentation/config complexity: multiple layers (Spark, Delta, cluster policies, workspace settings) can be hard to reason about.
Feature maturity varies by cloud/region: some serverless or newer features may lag by cloud.
Cost surprises: defaults (e.g., compute modes, Photon defaults, serverless enablement) can change and require governance.
Operational overhead: CI/CD, environment management, and workspace sprawl can become a burden.

Roadmaps are not reliably public; treat any roadmap claims as tentative unless Databricks provides written commitments.

- **Small teams with light workloads:** Spark cluster startup/operational overhead can dominate; simpler tools may be cheaper and faster. - **Organizations needing very predictable, simple billing:** DBU + cloud infra split can be challenging without strong FinOps. - **Analytics-only organizations (mostly BI, high concurrency, governance-first):** A warehouse-first platform (Snowflake/BigQuery) may be a more suitable primary home. - **Strict policies against serverless or compute outside the customer’s cloud account:** some managed features may be restricted under such policies. - **Organizations that prefer to avoid notebook-centric workflows:** Some practitioners report notebook-centric experiences; if an organization requires pure IDE/GitOps workflows, validate fit carefully. Based on recurring community and review signals (not exhaustive): - **Documentation/config complexity:** multiple layers (Spark, Delta, cluster policies, workspace settings) can be hard to reason about. - **Feature maturity varies by cloud/region:** some serverless or newer features may lag by cloud. - **Cost surprises:** defaults (e.g., compute modes, Photon defaults, serverless enablement) can change and require governance. - **Operational overhead:** CI/CD, environment management, and workspace sprawl can become a burden. Roadmaps are not reliably public; treat any roadmap claims as tentative unless Databricks provides written commitments.

Where it struggles

Small-data or highly interactive local-style workflows where users expect instant startup and minimal platform friction
Organizations that require strict separation and simple-to-administer controls for analysts vs engineers; practitioners report challenges locking down workspaces cleanly

02Why they buy

Validated by review themes and public descriptions:

Integrated platform across data engineering, analytics, and ML—frequently noted by users and documentation.
Collaboration features: shared workspace and notebooks enable interaction between DS and DE practitioners.
Distributed processing for Spark workloads: commonly cited as a strength where distributed compute is required.

Balanced counterpoints:

An integrated platform increases the surface area to govern, which can raise operational complexity.
Some users request better support for non-Spark workloads and improved ergonomics for small-data workflows.

Validated by review themes and public descriptions: - **Integrated platform** across data engineering, analytics, and ML—frequently noted by users and documentation. - **Collaboration features:** shared workspace and notebooks enable interaction between DS and DE practitioners. - **Distributed processing for Spark workloads:** commonly cited as a strength where distributed compute is required. Balanced counterpoints: - An integrated platform increases the surface area to govern, which can raise operational complexity. - Some users request better support for non-Spark workloads and improved ergonomics for small-data workflows.

Why customers chose Databricks (common themes)

Consolidation: a single platform for ETL, analytics, and DS/ML
Managed Spark runtime and distributed processing
Collaboration via notebooks and shared workspaces enabling interaction across roles
Lakehouse approach for ML datasets (bronze/silver/gold patterns are frequently discussed)

03Field reports

Note: Some platforms restrict full-text access; where only excerpts/summary are available, treat quotes as partial.

Review platforms (Gartner Peer Insights, G2, TrustRadius, AWS Marketplace)

Gartner Peer Insights (example sentiments)

Positive/neutral: Reviewers describe Databricks as capable and commonly used for data integration and analysis, while noting it can be daunting at first because many features are included. (Examples shown on the product page include a range of positive ratings and repeated emphasis on the learning curve.)
Governance caution: Another Gartner excerpt highlights the platform is strong but needs disciplined governance and structured adoption; otherwise complexity increases.

G2 (example excerpt)

A G2 review excerpt flags: “complex and overwhelming for new users,” “steep learning curve,” and that “pricing can become expensive as usage scales” and “cost management isn’t always very transparent.” It also notes debugging/performance issues can be challenging in large workflows.

TrustRadius (example excerpt)

Positive: One reviewer describes Databricks as the main data platform for landing/standardizing/transforming data with Workflows automation and dashboards.
Critical: The same TrustRadius excerpt lists cons like limited support for non-Spark workloads and difficulty hosting JAR files on certain serverless endpoints, and states smaller use cases may find the barrier to entry too high; Spark job startup overhead can make some workloads slower.

AWS Marketplace reviews (example sentiment)

Buyers cite Databricks as an integrated, scalable platform for large-scale processing and collaboration; marketplace review snippets skew positive but are often short and less critical than community threads.

Trustpilot (very limited sample size)

Trustpilot shows a very small number of reviews; one user says it is hard to get flexibility when working locally, though notebooks are noted as functional. Because the sample is tiny, treat as anecdotal.

**Gartner Peer Insights (example sentiments)** - Positive/neutral: Reviewers describe Databricks as capable and commonly used for data integration and analysis, while noting it can be daunting at first because many features are included. (Examples shown on the product page include a range of positive ratings and repeated emphasis on the learning curve.) - Governance caution: Another Gartner excerpt highlights the platform is strong but needs disciplined governance and structured adoption; otherwise complexity increases. **G2 (example excerpt)** - A G2 review excerpt flags: “complex and overwhelming for new users,” “steep learning curve,” and that “pricing can become expensive as usage scales” and “cost management isn’t always very transparent.” It also notes debugging/performance issues can be challenging in large workflows. **TrustRadius (example excerpt)** - Positive: One reviewer describes Databricks as the main data platform for landing/standardizing/transforming data with Workflows automation and dashboards. - Critical: The same TrustRadius excerpt lists cons like limited support for non-Spark workloads and difficulty hosting JAR files on certain serverless endpoints, and states smaller use cases may find the barrier to entry too high; Spark job startup overhead can make some workloads slower. **AWS Marketplace reviews (example sentiment)** - Buyers cite Databricks as an integrated, scalable platform for large-scale processing and collaboration; marketplace review snippets skew positive but are often short and less critical than community threads. **Trustpilot (very limited sample size)** - Trustpilot shows a very small number of reviews; one user says it is hard to get flexibility when working locally, though notebooks are noted as functional. Because the sample is tiny, treat as anecdotal.

Community / social (Reddit)

Reddit threads provide more candid “day-2 operations” commentary:

One r/datascience thread includes a critical take: Databricks is often used by practitioners with strong systems engineering background, plus complaints about schema management and governance (note: Unity Catalog has evolved since some older threads; still, these comments reflect the perception of operational burden).
A newer r/databricks thread “What do you dislike about Databricks?” criticizes documentation quality for configurations, difficulty understanding how configurations flow, and suggests some operations (e.g., clustering / optimization controls) feel awkward.
Multiple cost-related threads discuss confusion and skepticism about serverless defaults and DBU cost differences between all-purpose and job compute.

Reddit threads provide more candid “day-2 operations” commentary: - One r/datascience thread includes a critical take: Databricks is often used by practitioners with strong systems engineering background, plus complaints about schema management and governance (note: Unity Catalog has evolved since some older threads; still, these comments reflect the perception of operational burden). - A newer r/databricks thread “What do you dislike about Databricks?” criticizes documentation quality for configurations, difficulty understanding how configurations flow, and suggests some operations (e.g., clustering / optimization controls) feel awkward. - Multiple cost-related threads discuss confusion and skepticism about serverless defaults and DBU cost differences between all-purpose and job compute.

Why some customers leave / consider alternatives (common themes)

Cost predictability: DBU plus cloud infrastructure costs can be hard to forecast
Operational complexity: cluster policies, security, CI/CD, environment management can be heavy
Lock-in perceptions: noted in competitor messaging and echoed by some community comments about notebooks/workflows
Microsoft Fabric pull in Microsoft-heavy shops (Power BI, capacity model), even if Fabric is perceived as less mature for certain big-data/ML workloads

- **Cost predictability:** DBU plus cloud infrastructure costs can be hard to forecast - **Operational complexity:** cluster policies, security, CI/CD, environment management can be heavy - **Lock-in perceptions:** noted in competitor messaging and echoed by some community comments about notebooks/workflows - **Microsoft Fabric pull** in Microsoft-heavy shops (Power BI, capacity model), even if Fabric is perceived as less mature for certain big-data/ML workloads

Vendor-published case studies

Databricks publishes customer stories (for example, a case study reports a customer achieved a significant reduction in processing time).

Critical evaluation:

These are vendor-published and typically do not disclose full methodology (dataset size, baseline architecture, cost tradeoffs, how the prior measurement was made, or whether the new approach affected cloud spend).
Useful as directional evidence of capability, but not a substitute for independent benchmarks or a controlled pilot.

Databricks publishes customer stories (for example, a case study reports a customer achieved a significant reduction in processing time). **Critical evaluation:** - These are vendor-published and typically do not disclose full methodology (dataset size, baseline architecture, cost tradeoffs, how the prior measurement was made, or whether the new approach affected cloud spend). - Useful as directional evidence of capability, but not a substitute for independent benchmarks or a controlled pilot.

Third-party / compilations

Aggregated customer quote sites compile excerpts and claims; these can be useful for quick scanning but often lack context and may be marketing-oriented.

04Best fit

Company sizes (practical ranges)

Most appropriate fit: Mid-sized to very large organizations with mature data teams and platform engineering/FinOps support.
Budget reality: Often justified when there is sustained ETL/ML scale or multiple teams sharing the platform.

Industries

Frequent adoption in data-intensive sectors: fintech, retail, media, SaaS, healthcare (with compliance configuration), and public sector (where supported).

Roles/personas

Decision makers: VP Data/Analytics, CDO, Head of Data Platform, CTO
Champions: Data Engineering leads, ML platform engineers
End users: Data scientists, analytics engineers, SQL analysts (depending on workspace controls)

Suitable qualification criteria

Existing or planned Spark-scale workloads (batch/streaming)
Need for shared governance across DE/DS/BI
Capacity to invest in platform standards (IaC, CI/CD, policies, cost controls)

Disqualifiers

Small workloads, few users, or primarily SQL BI needs where overhead outweighs benefits
No platform engineering capacity (or unwillingness to manage clusters/policies/cost controls)

05The pitch

What the product does (objective value proposition)

Databricks Data Science refers to the data science and machine learning capabilities within the Databricks Data Intelligence Platform (Lakehouse): collaborative notebooks, distributed compute (Spark), ML lifecycle tooling (e.g., MLflow integrations), feature engineering patterns, model training at scale (including GPU options), and operationalization (jobs/workflows, model serving integrations depending on edition/cloud). Databricks positions this as an integrated environment where data engineering, analytics/BI, and DS/ML can operate on the same governed data with shared governance controls. (Official positioning is broader than “data science” alone.)

Target market and positioning

Primary target: Mid-market to large enterprises running multi-persona data teams (data engineering + analytics + ML) that need a shared platform for large-scale processing and governance.
Secondary target: Organizations standardizing on a major cloud (AWS/Azure/GCP) that want a managed Spark/lakehouse platform.
Typical positioning themes in reviews: described as a single platform or integrated platform, with emphasis on collaboration and scale; common counterpoints include complexity and a steep learning curve.

- **Primary target:** Mid-market to large enterprises running multi-persona data teams (data engineering + analytics + ML) that need a shared platform for large-scale processing and governance. - **Secondary target:** Organizations standardizing on a major cloud (AWS/Azure/GCP) that want a managed Spark/lakehouse platform. - **Typical positioning themes in reviews:** described as a single platform or integrated platform, with emphasis on collaboration and scale; common counterpoints include complexity and a steep learning curve.

Get a comprehensive analysis of Databricks Data Science including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →