Databricks vs Redshift

Quick verdict

Databricks builds on the lakehouse model: data is stored as files in cloud object storage (Amazon S3 on AWS) and organised into tables by an open table format. Delta Lake is the default format for all operations on Databricks, and managed Iceberg tables are also supported. Unity Catalog governs tables, volumes, models and functions, with lineage and auditing. Compute comes as Spark clusters in your AWS account, serverless compute run by Databricks, and SQL warehouses (serverless, pro or classic) for SQL and BI, with the Photon vectorised engine enabled on SQL warehouses and serverless compute. Databricks also runs on Azure and Google Cloud.

Amazon Redshift is AWS's managed data warehouse. A provisioned cluster has a leader node that parses queries and builds plans and compute nodes that run them in parallel. AWS recommends its RG node types (Graviton based, with an integrated data lake query engine) or RA3 node types, both using Redshift managed storage, which keeps hot data on local SSDs and offloads the rest to Amazon S3 so that compute and storage are paid for separately. Redshift Serverless removes cluster management and measures capacity in Redshift Processing Units (RPUs). Redshift queries data lake tables in S3 through the AWS Glue Data Catalog, and Redshift ML trains models through Amazon SageMaker AI.

Side by side

Key differences

Lakehouse on S3 versus a warehouse with managed storage

On Databricks, the tables are the files in object storage: a Delta Lake table is Parquet files plus a transaction log that provides ACID transactions, versioned history and time travel, and the same tables serve batch and streaming jobs, SQL warehouses and ML. Unity Catalog adds permissions, lineage and auditing, and Lakehouse Federation can query other systems, including Amazon Redshift, read-only without copying the data.

Redshift is a warehouse first. Data loaded into Redshift lives in Redshift managed storage on RG or RA3 nodes, which AWS describes as large local SSDs with automatic offload to Amazon S3, billed at one storage rate wherever the data sits. Data in S3 is reached through external schemas over the AWS Glue Data Catalog. AWS documents that RG clusters and Redshift Serverless use their own compute for these data lake queries, while RA3 and DC2 clusters use Redshift Spectrum, which is billed separately per TB scanned. In our view, Redshift suits teams that want a conventional warehouse with a lake alongside it; Databricks suits teams that want the lake to be the warehouse.

Compute and scaling: SQL warehouses versus clusters and RPUs

Databricks offers three SQL warehouse types. Serverless warehouses run in Databricks' serverless compute plane, typically start in 2 to 6 seconds and include Photon, Predictive IO and Intelligent Workload Management. Pro and classic warehouses run in your AWS account and typically take about 4 minutes to start; pro includes Photon and Predictive IO, classic includes Photon only. Data engineering and ML run on Spark clusters or serverless compute.

Redshift provisioned clusters are sized by node type and count; AWS supports elastic resize, pausing a cluster (you then pay only for backup storage) and reserved nodes for steady workloads. Redshift Serverless measures capacity in RPUs, each with 16 GB of memory; the default base capacity is 128 RPUs and it can be set from 4 to 512 RPUs (1,024 in some regions). AI-driven scaling, enabled by default on new workgroups at a "Balanced" price-performance target, adjusts RPUs to the workload, and Max capacity and Max RPU-hours settings cap spend.

Open table formats: Iceberg on both, Delta Lake mainly on Databricks

Databricks creates Delta tables by default and managed Iceberg tables with USING ICEBERG in Unity Catalog. Iceberg tables catalogued in AWS Glue can be attached as foreign Iceberg tables, which are read-only in Databricks, and external engines can read and write Unity Catalog Iceberg tables through the Iceberg REST Catalog API.

Redshift can query Iceberg tables in the AWS Glue Data Catalog and, according to its documentation, create and write them in Amazon S3 and S3 table buckets, on both provisioned clusters and Serverless. Supported Iceberg statements include CREATE TABLE ... USING ICEBERG, INSERT, DELETE, UPDATE and MERGE, for Iceberg v2 and v3 tables. AWS also documents that time travel queries on Iceberg tables are not currently supported in Redshift.

-- Amazon Redshift: Iceberg table in an external schema backed by AWS Glue
CREATE TABLE lake.orders (order_id INT, amount DECIMAL(10,2))
USING ICEBERG
LOCATION 's3://amzn-s3-demo-bucket/orders/';

INSERT INTO lake.orders VALUES (1001, 49.90);

-- Databricks SQL: Delta by default, Iceberg on request
CREATE TABLE main.sales.orders (order_id BIGINT, amount DECIMAL(10,2));
CREATE TABLE main.sales.orders_ice (order_id BIGINT, amount DECIMAL(10,2)) USING ICEBERG;

For Delta Lake, Redshift Spectrum reads tables through manifest files that you generate. AWS notes that manifests provide only partition-level consistency and that queries fail if a manifest points to files that no longer exist, for example after a VACUUM, until a new manifest is generated. If the two products will share data, Iceberg is the format both document for reading and writing.

Machine learning and AI

Databricks documents a full ML stack: MLflow for experiments and the model lifecycle, Model Serving for custom models and LLMs as REST endpoints, a Feature Store governed by Unity Catalog, AI Gateway, Ray, and serverless GPU compute for training and inference.

Redshift ML exposes models through SQL. CREATE MODEL exports training data to S3 and uses Amazon SageMaker AI Autopilot to choose and train a model, then registers a prediction function in Redshift; AWS notes that training is billed as a separate SageMaker AI line item, while inference with models compiled to run on the cluster carries no extra Redshift charge. Redshift ML can also call Amazon Bedrock foundation models from SQL. One change to plan for: AWS states that Redshift no longer supports Python UDFs after 30 June 2026 and is enforcing this in phases, so existing Python UDFs need migrating; AWS's announcement describes the options.

Pricing and licensing

Databricks bills Databricks Units (DBUs) per second at a rate set by compute type (for example jobs compute, all-purpose compute, SQL Classic, SQL Pro, SQL Serverless), plan and region. On classic compute, which runs in your AWS account, AWS also bills you for the EC2 instances, storage and networking. For serverless compute and serverless SQL warehouses, Databricks documents that the DBU charge covers the underlying compute. Databricks' own price tables load dynamically, so use its pricing calculator for AWS rates; as one published example, Microsoft's Azure Retail Prices API listed the Azure Databricks Premium Serverless SQL DBU in East US at USD 0.70 per DBU-hour in October 2026 (Azure Databricks prices are set by Microsoft). Committed-use contracts give discounts. Free Edition is free for non-commercial use only; a 14-day trial is also offered.

Amazon Redshift has two compute models. Provisioned clusters are billed per node-hour, on demand or with reserved-node discounts, at rates that depend on node type and region. Redshift Serverless is billed per RPU-hour while the warehouse is active, with a 60-second minimum charge; the pricing page lists USD 0.375 per RPU-hour in US East (N. Virginia), with a minimum base capacity of 4 RPUs. Redshift managed storage is billed per GB-month (USD 0.024 in US East (N. Virginia)), and Redshift Spectrum queries from RA3 and DC2 clusters are billed per TB scanned. New Redshift Serverless users get USD 300 of credit, valid for 90 days.

In our view, a fair cost comparison needs the same workload sized on both: Databricks' cost follows how long compute runs and at what size (plus EC2 on classic compute), while Redshift's follows node-hours or RPU-hours and stored data.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You want a managed warehouse that runs on any major cloud: see Snowflake vs Databricks and Snowflake vs Redshift.
• You are not tied to AWS and want a serverless warehouse: see BigQuery vs Redshift and Databricks vs BigQuery; on Microsoft's stack, Databricks vs Microsoft Fabric.
• You need sub-second dashboards or APIs over event data: a real-time OLAP database may fit better; see ClickHouse vs Databricks.
• Your data still fits a PostgreSQL server: you may not need a warehouse yet; see Redshift vs PostgreSQL and data warehouse vs database.

Final recommendation

Frequently asked questions

Sources

• Databricks pricing
• Databricks: SQL warehouse types
• Databricks: Serverless compute
• Databricks: What is Delta Lake
• Databricks: Unity Catalog
• Databricks: Apache Iceberg support
• Databricks: Lakehouse Federation
• Databricks: AI and machine learning
• Azure Databricks pricing (Microsoft)
• Amazon Redshift pricing
• Amazon Redshift provisioned clusters and node types
• Amazon Redshift Serverless compute capacity
• Amazon Redshift: Using Apache Iceberg tables
• Amazon Redshift: Writing to Apache Iceberg tables
• Amazon Redshift Spectrum external tables (Delta Lake)
• Amazon Redshift ML

Checked October 2026.

How we research comparisons: our editorial method.