Cost Comparison#
Version |
1.0 |
Date |
2026-10-30 |
Where the money goes in each approach. This is a hypothetical, relative comparison for one reference scenario, not a quote. Vendor pricing changes often and depends heavily on workload and negotiation, so the page uses symbols rather than dollar figures. The platform will publish measured numbers (its own monthly AWS bill, the cost per burst run, the cost of a disaster-recovery drill) as they are collected.
Scale: 0 none · + low · ++ moderate · +++ high · ++++ highest. Read each row across: the symbols compare the approaches for that cost driver only. Rows are not weighted against each other. “—” means not applicable.
Reference scenario: a small data team (3–5 engineers), a lake of around a terabyte, daily batch pipelines, regular interactive work in notebooks and SQL, occasional heavy jobs, and a few dashboards.
The approaches#
Approach |
|
|---|---|
Snowflake |
Managed warehouse, billed in credits |
Databricks |
Managed lakehouse, billed in DBUs plus the cloud infrastructure underneath |
dbt Cloud |
Managed transformation, billed per seat, plus the warehouse it runs on (one of the columns above) |
All-AWS, open source |
The same open source stack, run entirely on AWS (containers, managed database, load balancer) |
opendatastack |
Hybrid: open source on owned hardware, plus a curated set of AWS services |
All on-prem |
The same open source stack with no cloud at all |
Comparison#
Cost driver |
Snowflake |
Databricks |
dbt Cloud |
All-AWS, open source |
opendatastack |
All on-prem |
|---|---|---|---|---|---|---|
Platform subscription (credits, DBUs, seats) |
++++ |
++++ |
++ |
0 |
0 |
0 |
Always-on cloud infrastructure |
0 (in credits) |
++ |
0 |
+++ |
+ |
0 |
Interactive compute (notebooks, SQL editors) |
+++ |
++++ |
(warehouse) |
++ |
0 |
0 |
Scheduled batch compute |
+++ |
+++ |
(warehouse) |
++ |
0 |
0 |
Burst / peak compute |
++ |
++ |
(warehouse) |
+ |
+ |
— |
Hot storage |
+ |
+ |
— |
+ |
0 |
0 |
Off-site backup and archive |
+ |
+ |
— |
+ |
+ |
++ |
Data egress |
+ |
+ |
— |
+ |
+ |
0 |
Owned hardware |
0 |
0 |
0 |
0 |
++ |
+++ |
Power, space, network |
0 |
0 |
0 |
0 |
+ |
+ |
Administration time |
+ |
++ |
+ |
+++ |
+++ |
++++ |
Cost to leave (lock-in) |
++++ |
+++ |
++ |
++ |
+ |
+ |
Why the hybrid scores the way it does#
No platform fee, and compute you already own. Batch and interactive work run on owned hardware. There is no credit or DBU meter running while a notebook is open, which is where managed platforms charge most: a warm cluster or warehouse for every interactive session.
A small, deliberate AWS bill. AWS is used for what it does cheaply: off-site backup and archive, identity, notifications, and compute for the occasional peak. The always-on line items that dominate an all-AWS build (load balancer, NAT gateway, managed database, always-running containers) are avoided. The target is a cloud bill that stays small and is watched by budget alerts.
Data gravity. Moving data into AWS is free and moving it out is not, so bulk data flows on-prem → AWS (backup, archive, burst inputs) and only small results come back.
Owned hardware is a real cost. It is sized for the steady workload, not the peak; burst compute covers the peaks, which keeps it smaller than an all-on-prem build that must be sized for the worst day.
Low cost to leave. Open formats (Delta tables, plain S3 storage), open source tools and a proven swap between on-prem and AWS keep the exit cost low, for any layer.
The honest trade-off#
Administration time is the largest real cost of any self-run platform, and the hybrid does not escape it: patching, upgrades, monitoring and the occasional bad day belong to the team. Managed platforms win when engineering time is scarcer or dearer than money, when usage is light enough that credits stay small, or when the organization needs a vendor’s support contract and certifications. The hybrid wins when interactive and batch work is steady, the team is comfortable running open source, and avoiding lock-in has value of its own.
Measured costs#
To come. As the AWS side is built, this section will record the platform’s own figures: the monthly AWS bill, the cost of each burst run next to the same job on-prem, and the time and egress cost of restoring a table from the off-site copy.
Revision history#
Version |
Date |
Changes |
|---|---|---|
1.0 |
2026-10-30 |
First version |