What Replaces What: Mapping Your Cloud Data Stack to One Self-Hosted Platform
Every team that decides analytics has to run inside their own boundary asks the same question, and it is not philosophical. It is a mapping question: we run Snowflake, Fivetran, dbt, Airflow, and Looker today. If we replace all of that with one platform we host ourselves, what replaces what?
Nobody publishes that map. Vendors publish feature grids. So here it is, layer by layer, with honest notes on what carries over cleanly, what gets rebuilt faster than it was built the first time, and what you should leave alone.
The right-hand column is Definite, a full-stack self-hosted data platform: connectors, a lakehouse (DuckLake + DuckDB), a semantic layer, dashboards, an AI analyst, and data apps. One Helm chart, deployed into your Kubernetes, in your cloud account, your data center, or fully air-gapped. If you searched for an on-prem full-stack analytics platform, this table is the answer to the question underneath the search.
The map
| Layer | You run today | In Definite | What actually ports |
|---|---|---|---|
| Storage + query | Snowflake, BigQuery, Databricks SQL | Lakehouse: DuckLake tables on your object store, queried by DuckDB | Analytical SQL, with dialect changes. Stored procedures and Spark jobs do not. |
| Ingestion | Fivetran, Airbyte | Built-in connectors + scheduled syncs | Nothing to port; it was configuration. Re-authenticate and backfill. |
| Transformation | dbt | SQL datasets on a schedule | Models port as SQL. Macros and tests need rework. |
| Orchestration | Airflow | Scheduled syncs + Python pipelines | Simple schedule-and-run DAGs map cleanly. Exotic DAGs need rework. |
| BI | Looker, Tableau, Power BI | Definite dashboards | Dashboards get rebuilt, not imported. The modeling underneath ports. |
| Metrics | LookML, Cube, dbt metrics | Definite semantic layer (YAML) | Dimensions, measures, and joins translate one-to-one. |
| AI on your data | Custom RAG / agent stack | Fi, the AI analyst | Replaces the build. You keep your model endpoint. |
| Internal tools | Streamlit apps | Data apps | Rebuilt on governed data. Heavy custom apps may stay as code. |
Now the nuance, row by row.
Storage and query: Snowflake, BigQuery, and Databricks SQL
The warehouse becomes a lakehouse: DuckLake tables on an S3-compatible object store you own, queried by DuckDB. Your data sits in open Parquet files in your own bucket, with the catalog in Postgres. Nothing about the storage layer is opaque or vendor-locked.
Analytical SQL mostly ports. DuckDB speaks standard SQL plus the conveniences you actually use (window functions, QUALIFY, lateral joins). What does not port: Snowflake stored procedures, tasks, and streams; BigQuery scripting; anything written for Spark. Those get re-expressed as SQL datasets and Python pipelines, or they stay where they are.
The other honest line: DuckDB is a single-node engine. A tuned single node with partition pruning covers the overwhelming majority of analytics workloads at sub-second latency, and it handles 100+ TB lakehouses. It does not cover petabyte-wide, shuffle-heavy Spark joins. If that is your daily work, keep Databricks for it.
Worth knowing if you got here by searching for on-prem versions of these tools: Snowflake cannot run on-premise in any form, and Databricks always keeps its control plane in its own SaaS, even when your clusters run in your VPC.
Ingestion: Fivetran and Airbyte
Managed EL becomes built-in connectors with scheduled syncs. There is no code to port here because there never was code, just configuration. The migration work is re-authenticating sources and running backfills, not rewriting anything.
The honest caveat is coverage. Common sources (Postgres, MySQL, Salesforce, HubSpot, Stripe, Shopify, the major ad platforms) are covered. If you depend on a long-tail SaaS connector, check your exact source list before you commit. Anything missing gets built as a Python pipeline inside the platform, calling the source API directly. That is more work than a checkbox, but the pipeline stays inside your boundary with everything else.
Transformation: dbt
dbt models are SELECT statements, and they port as SQL datasets: the same SQL, running on a schedule, with dependencies between datasets standing in for the dbt DAG. For most projects this is the smoothest row in the table.
Three things need real rework. Jinja macros get expanded into plain SQL. Incremental materialization logic gets re-expressed. And dbt tests get re-authored (a not-null check is one line of SQL, but someone has to write it). A 40-model project moves in days. A 400-model project with a deep macro library moves in weeks, and you should budget for that honestly.
Orchestration: Airflow
Most Airflow usage in an analytics stack is a schedule: sync these sources, then run these transforms, then refresh these dashboards. That maps directly to scheduled syncs and Python pipelines with triggers, and it is the part of Airflow nobody enjoys operating anyway.
The part that does not map: deeply customized DAGs. Custom operators, dynamic DAG generation, sensors watching external systems, DAGs that orchestrate work far outside analytics. Definite replaces analytics orchestration, not general-purpose workflow infrastructure. If Airflow does both jobs for you, split them: move the analytics schedule in, leave the rest where it is.
BI: Looker, Tableau, and Power BI
Dashboards get rebuilt, not imported. Nobody converts a Tableau workbook faithfully, including us, and you should be skeptical of anyone who says otherwise.
Two things make the rebuild far cheaper than the original build. First, the modeling underneath ports (next row), and a dashboard on top of a good semantic layer is minutes of work, not weeks. Second, Fi does most of the rebuilding: describe the dashboard and it assembles the queries and charts from governed metrics.
Credit where due: Tableau's visualization depth is real, and Power BI Pro comes bundled into Microsoft 365 E5, which is hard to argue with on price. What you get in exchange for the rebuild is one system instead of three, sub-second DuckDB-powered dashboards, and BI that lives inside the same boundary as the data.
Metrics: LookML, Cube, and dbt metrics
Definite's semantic layer is YAML: models, dimensions, measures, joins. If you have LookML or Cube definitions, the concepts map one-to-one and the rewrite is mechanical, closer to transcription than translation. dbt metrics port the same way, as measures.
Mechanical does not mean free. Years of LookML with heavy Liquid templating hide business logic inside the templating layer, and that logic has to be made explicit on the way over. Most teams find the exercise overdue anyway.
This layer matters more than it looks. In Definite the semantic layer is not optional: dashboards and Fi both read from it, so a metric means one thing everywhere, including to the AI.
AI on your data: the custom RAG stack
Over the last two years a lot of teams built the same internal project: a vector store, schema retrieval, a prompt pipeline, a SQL-writing agent, and a slowly growing eval suite, all so people can ask questions about company data. Fi replaces that build. It reads the semantic layer, writes SQL against the lakehouse, builds dashboards, and shows its work.
Because this whole map is self-hosted, Fi runs inside your tenant and calls a model endpoint you control: Amazon Bedrock, Azure OpenAI, Vertex, or self-hosted open weights. Schemas, prompts, and results stay inside your boundary.
The scope caveat: Fi is a data analyst. If your agent stack also handles support triage or document search, that work is not replaced by this row.
Internal tools: Streamlit
Streamlit apps exist because dashboards stop at charts. Someone needed a filterable table, a small form, a tool for the ops team, so they wrote Python. Those become data apps: small internal apps built on the same governed data as everything else, and Fi can build them from a description.
The caveat: an app with heavy custom components or write paths into external systems may deserve to stay as code you own. The common case (a lookup tool, an internal report, a one-screen workflow) moves.
Where the map breaks
Three things this platform does not replace, stated plainly:
- Petabyte-scale Spark. DuckDB is a single-node engine. Wide, shuffle-heavy joins over petabytes belong on Databricks or your own Spark cluster.
- Event stream processing. Kafka and Flink are a different category. Definite ingests continuously and on schedules for analytics; it is not a stream processor.
- General-purpose orchestration. If Airflow also runs your ML training and your invoice processing, keep it for those jobs. Move the analytics schedule.
If a vendor tells you their platform replaces everything with no residue, they are describing a slide, not a migration.
One Helm chart, one boundary
Everything above deploys as a single Helm chart into your Kubernetes: your cloud account, your data center, or fully air-gapped with a self-hosted model and zero required egress. There is no vendor control plane on the other end of a required connection, which is exactly the failure mode that pushes teams toward a self-hostable stack in the first place.
For the procurement checklist: SOC 2 Type II is complete (trust.definite.app), we sign HIPAA BAAs, and for public sector work Definite deploys into your FedRAMP-authorized environment.
That is what "full-stack self-hosted data platform" means in practice. Not a query engine you assemble a stack around. Not a BI tool pointed at a warehouse someone else operates. Every layer in the table, one deployment, inside your boundary.
FAQ
What replaces Snowflake, BigQuery, or Databricks SQL in a self-hosted stack? A lakehouse: DuckLake tables on an object store you own, queried by DuckDB. Analytical SQL ports with dialect changes. Stored procedures, tasks, and Spark jobs do not port, and petabyte-scale shuffle-heavy Spark work should stay on Spark.
Do dbt models carry over to Definite? Mostly yes. dbt models are SELECT statements and port as SQL datasets, with dependencies between datasets standing in for the dbt DAG. Jinja macros get expanded into plain SQL, incremental materialization logic gets re-expressed, and tests get re-authored.
What happens to our Airflow DAGs? Schedule-and-run DAGs (sync these sources, run these transforms, refresh these dashboards) map to scheduled syncs and Python pipelines. Deeply customized DAGs with custom operators, dynamic generation, or non-analytics jobs need rework or should stay in Airflow. Definite replaces analytics orchestration, not general-purpose workflow infrastructure.
Do Looker or Tableau dashboards migrate automatically? No, and no vendor does this faithfully. Dashboards get rebuilt. The rebuild is fast because the metric definitions port to the semantic layer first, and Fi can assemble dashboards from those governed metrics on request.
Can the whole platform run air-gapped? Yes. Definite deploys as a single Helm chart into your Kubernetes, and Fi calls a model endpoint you control, including self-hosted open weights. A fully disconnected deployment with zero required egress is supported.
What about SOC 2, HIPAA, and FedRAMP? SOC 2 Type II is complete (see trust.definite.app) and Definite signs HIPAA BAAs. For public sector work, Definite deploys into your FedRAMP-authorized environment rather than claiming its own authorization.
If you want this map drawn on your actual stack, the deployment architecture is on the private deployment page, or grab 30 minutes and I'll walk through what ports, what gets rebuilt, and what should stay put.