Split View: 2026년 데이터 도구 지형 읽는 법 — 도구 목록이 아니라 층별 결정으로

How to Read the 2026 Data Tooling Landscape — Layer-by-Layer Decisions, Not a Tool List

• Introduction — A 51-Point Map, and What a Map Doesn't Decide for You
• Five Layers, and the Real Decision at Each One
• Ingestion — The Decision Is Ownership, Not Connectors
• Storage — the Format War Is Over, and the Fight Moved to the Catalog
• Transformation and Orchestration — Where the Compiler Sits, and the Failure-Handling Model
• Where the Boundaries Are Collapsing — Compute Gets Pulled Back to the Local Machine
• Where the Market Is Consolidating
• Six Questions That Actually Decide Which Tool You Pick
• Conclusion — the Landscape Changes, But the Questions Remain
• References

Introduction — A 51-Point Map, and What a Map Doesn't Decide for You

On July 28, 2026, A Data Tooling Landscape Guide for Developers landed on GeekNews and picked up 51 points. The original post targets software developers who are just setting foot in data for the first time, and walks through the whole loop from ingestion to storage, processing, orchestration, consumption, and governance. File formats (CSV, Parquet, ORC, Avro, Arrow), warehouses versus lakes versus lakehouses, ingestion tools (Fivetran, Airbyte, dlt, Debezium), transformation (dbt, SQLMesh), distributed processing (Spark, Dask, Ray, Flink), orchestration (Airflow, Dagster, Prefect), the medallion architecture, semantic layers and catalogs, and BI tools — as a list, it's thorough.

It's a good map. But a map doesn't choose your destination for you. The real difficulty in this field isn't "Airbyte or Fivetran" — it's picking a tool without knowing what decision you're actually making at this layer. So six months later, you're having the same argument at the same layer all over again.

This post redraws the same landscape, but instead of tool names at each layer, it builds around the axis of decision. And it flags where, as of 2026, those axes are starting to buckle.

Five Layers, and the Real Decision at Each One

There are several ways to slice the layers, but cutting at the points where the nature of the decision changes gives you five.

That third column is the entire point of this post. Tool names change every three years; those questions don't. Let's go through them one at a time below.

Ingestion — The Decision Is Ownership, Not Connectors

At the ingestion layer, what people usually compare is connector count and price. What actually diverges is a different axis.

Do you maintain the connector, or hand it to someone else. SaaS APIs like Salesforce or Stripe change schema without warning, quietly tighten rate limits, and shift pagination one day without notice. The value of a managed ingestion service isn't the connector itself — it's the headcount that chases those changes for you. Conversely, if your sources are just a handful of internal Postgres instances, you don't need to buy that headcount, and a managed service's per-row pricing becomes pure waste.

Do you need change data capture. Batch-rereading everything and streaming only the changes off a WAL are operationally worlds apart. Debezium-style CDC has to hold a logical replication slot on the source database, and if the slot falls behind, the source DB's disk fills up — which means a failure in the ingestion pipeline can cascade into a failure of the production DB. Whether freshness matters enough to take on that risk is the real decision here.

Who defines the schema of the extracted data. Copying the source schema as-is (ELT's default) gets you started fast, but if the source team drops a column, everything downstream breaks. Specifying an explicit contract is slower, but the breakage stops at the ingestion point. Organization size determines this choice — if the source team and the data team sit in the same room, the former is enough; if they're in different departments, you need the latter.

This is also why writing pipelines directly with a Python library (the dlt family) has gained traction lately. It's the middle ground where you own the connector but hand the boilerplate to the library, and it's generally the cheapest option when you have ten sources or fewer.

Storage — the Format War Is Over, and the Fight Moved to the Catalog

For years the question at this layer was "Iceberg, Delta, or Hudi." As of 2026, that question is largely settled.

The Iceberg v3 spec was ratified in mid-2025, and through the 1.10–1.11 release line it picked up deletion vectors, a variant type for semi-structured data, row lineage, and geospatial types. Snowflake, Databricks, and Amazon S3 Tables have all declared v3 support GA. What matters here is that the features v3 absorbed were originally Delta Lake's points of differentiation. With deletion vectors and row lineage now in Iceberg, the very choice between "performance or interoperability" has disappeared. Databricks went a step further, proposing an adaptive metadata tree for Iceberg v4 and saying Delta 5.0 would adopt the same structure. The direction is convergence.

Once formats converge, where does lock-in go — the catalog. This is the service that tells you which tables exist and where their latest metadata files are, and access control, auditing, and credential vending attach here. The Iceberg REST catalog spec has become the de facto interface, and Apache Polaris, Unity Catalog, AWS Glue, and each cloud's own implementation compete on top of it.

And the catalog layer still isn't uniform. v3 features flow through the catalog API, and not every catalog supports creating v3 tables — as of mid-2026, AWS Glue is reported not to be able to create v3 tables through the REST CreateTable path (engines can still handle it on their side). Which means saying "we use Iceberg" is no longer a sufficient description. What you actually need to ask is this:

• Which catalog are you using, and if you switch catalogs, do you have to rewrite the data
• Can your engines (Spark, Trino, DuckDB, each warehouse) attach to that catalog's REST implementation
• How many engines have write access — and if more than one, who guarantees handling of concurrent write conflicts

There's a way to check these three things by hand instead of by argument: read the same table with a tool other than the vendor's own console. It takes thirty minutes, and it's the most honest test of an openness claim.

-- Attach directly to a REST catalog from DuckDB.
-- If this works without going through the warehouse's console, the table is genuinely open.
INSTALL iceberg; LOAD iceberg;
INSTALL httpfs;  LOAD httpfs;

CREATE SECRET catalog_auth (
    TYPE ICEBERG,
    CLIENT_ID     'svc-analytics',
    CLIENT_SECRET 'redacted'
);

ATTACH 'my_warehouse' AS lake (
    TYPE ICEBERG,
    ENDPOINT 'https://catalog.internal.example.com/api/catalog'
);

SHOW ALL TABLES;
SELECT count(*) FROM lake.analytics.orders WHERE order_date >= DATE '2026-07-01';

-- If snapshot history shows up, time travel and rollback are yours too
SELECT * FROM iceberg_snapshots('lake.analytics.orders');

# Check, without going through the catalog, whether the table structure survives
# by looking at the object store alone
aws s3 ls s3://lake-prod/analytics/orders/metadata/ --human-readable | tail -5
# If you see v00042-....metadata.json and snap-....avro,
# the data survives even if you swap out the catalog

How a v3-era feature like row lineage is actually stored and what it guarantees is covered separately in Iceberg v3 Row Lineage — Row IDs Aren't Stored in the File.

Meanwhile, this layer also has a challenger coming from a different direction. DuckLake, built by the DuckDB Foundation, manages metadata not as a file tree but by putting it in a SQL database. You can use PostgreSQL, SQLite, or DuckDB as the catalog backend, and the data itself stays Parquet. v1.0 shipped in April 2026 with a backward-compatibility guarantee. The argument is simple — metadata lookups are exactly what a database is already good at, so why are we digging through a file tree on top of object storage instead? That said, adoption isn't at a scale comparable to Iceberg yet, and it's still early to adopt as an organization-wide standard shared across multiple engines.

Transformation and Orchestration — Where the Compiler Sits, and the Failure-Handling Model

The real decision at the transformation layer is "where does the SQL get compiled, and where does it run." dbt-family tools never touch data directly. They expand SQL templates into a dependency graph, compile it into the warehouse's dialect and dispatch it, and materialize the result as a table or view. In other words, it's a compiler and a build system at once. So what you actually need to ask at this layer is:

• Can the tool know the dependency graph between models statically, or only by running it? If it knows statically, impact analysis and partial re-runs become possible.
• Does the compiled output run on any engine? How much transformation code you'd need to rewrite when switching warehouses hinges on this.
• Who guarantees the correctness of incremental materialization? Late-arriving data and backfills produce more bugs at this layer than anything else.

Looking at these three together, you can read the movement of the last few years. The industry is shifting from rendering Python template strings toward actually parsing SQL to statically know column-level lineage, and dbt's Fusion engine and SQLMesh are both headed the same direction.

The real decision at the orchestration layer isn't scheduling — it's failure handling. cron can schedule things too. The reason you adopt an orchestrator is the behavior where "when the 3am job fails, the 5am job automatically halts, and once the cause is fixed, only those two re-run." So what you need to ask is:

• Is the unit of failure a task, or a data asset? With the latter, the system knows whether "this table is up to date" and computes the scope of a re-run itself.
• Is backfill a first-class concept? Whether re-running the last 90 days is a single button or an ad hoc script determines your operational burden.
• Does streaming fit into this graph at all? Most orchestrators are built for batch DAGs, and streaming pipelines have a different lifecycle. Force it into one tool and both ends end up awkward.

Airflow 2 has passed EOL, so this layer is genuinely in the middle of moving right now. What the real task list looks like when migrating to 3.x is covered in After Airflow 2's EOL — the Real Task List from 2 to 3.

Where the Boundaries Are Collapsing — Compute Gets Pulled Back to the Local Machine

The default assumption of the last decade was "data is big, so it goes to a cluster." That assumption is eroding from two directions.

One is hardware. 32–64GB of memory is now common on a laptop, and NVMe reads at gigabytes per second. And the data most analytical queries actually touch is far smaller than people assume — with columnar storage reading only the needed columns, and partition pruning reading only the needed partitions, it's common to scan just a few hundred MB out of a terabyte-scale table.

The other is the maturity of single-node engines. DuckDB, Polars, and DataFusion now have vectorized execution and disk-spilling for data larger than memory, and they read Parquet and Iceberg tables on S3 directly. As a result, a substantial share of the work that used to require "spin up a cluster and point your laptop at it to run one line of SQL" has come down to a single binary.

This shift creates three practical changes.

• The development loop gets shorter. You run transformation logic locally against an actual data sample and commit. Cluster queues disappear.
• The cost structure changes. A warehouse's compute billing is per query, and when exploratory analysis moves local, that bill disappears.
• The boundary blurs. With DuckDB gaining a client-server protocol (the Quack remote protocol in v1.5.3, May 2026), the line between an "embedded engine" and a "query service" has gotten fuzzy. What that change actually alters and what it doesn't is covered in DuckDB Now Has a Client-Server Protocol.

Clusters aren't disappearing, of course. The line is clear — does the data touched by a single query fit in one machine's memory and disk, and are multiple people doing that work at the same time. If the answer to the first is no, you need distribution; if the answer to the second is yes, you need a server. A plan to run an entire organization's overnight batch on a local engine is usually regretted six months later. So is spinning up a Spark cluster for one analyst's exploratory work.

Spark hasn't been standing still either — its Python UDF path has been rebuilt on Arrow, cutting serialization cost between Python and the JVM substantially. See PySpark 4.2 Makes Arrow UDFs the Default.

Where the Market Is Consolidating

Having covered the decision at each layer, we should also look at how those layers are merging into one. The biggest event of 2026 is the merger of Fivetran and dbt Labs. Announced October 13, 2025 and completed June 1, 2026, it was an all-stock deal, and per the press release the combined company serves more than 100,000 data teams. George Fraser is CEO, Tristan Handy is President. (A combined-ARR figure gets cited often, but the press release itself has no number, so I won't quote one here.)

The significance of this merger is the fourth column of the table above. Ingestion and transformation are now under one roof. It used to be a virtue of the modern data stack to assemble the best tool at each layer — "ingestion from A, storage from B, transformation from C, orchestration from D" — and this merger is also an admission that the cost of that assembly (metadata breaking at every layer boundary, lineage not carrying through, having to trace failure causes across layers) was, in practice, substantial.

At the same time, this company's target is clear — all-in-one platforms like Snowflake, Databricks, and Microsoft Fabric. And what it's positioning as its differentiator is open standards. It's staking its position on SQL and Iceberg, and has in fact put the dbt Fusion engine runtime into dbt Core v2.0 (alpha) under Apache 2.0.

Two things are worth taking away here.

First, layer boundaries no longer line up with vendor boundaries. The strategy of "we use the best tool at each layer" is, in practice, becoming "we use a bundle from three vendors." When picking a tool, you need to look at what else the bundle it belongs to drags in with it.

Second, the price of consolidation is always migration cost. There's exactly one way to check whether the promise of sitting on open formats is real — count what's left after you delete the vendor. If tables remain in Iceberg, the catalog can be pointed at a different implementation, and the transformation SQL runs on a different engine, the promise is real. If any one of the three doesn't hold, it's marketing.

Six Questions That Actually Decide Which Tool You Pick

Compressed into a single checklist, the per-layer decisions come out to this. It narrows down an answer far faster than a vendor comparison chart.

1. Who reads this data, and how fresh does it need to be? If it's only people looking at a dashboard in the morning, batch is enough; if it feeds a product surface, you need a serving layer and a latency budget. This one question mostly decides whether you need streaming at all.
2. Does the data touched by your single biggest query fit on one machine? If it does, you don't need a distributed engine yet — this is the boundary from the previous section.
3. When this pipeline fails, what recovers automatically, and what does a human have to do? If the answer here is "a human does everything," fix the operating model before you reach for an orchestrator.
4. Where does the single definition of a metric live? If a BI tool, a notebook, and product code are each computing "active users" on their own, buying one more tool won't fix it.
5. If you deleted this tool, where and in what form would the data remain? This is the only question that actually tests an open-format claim.
6. How many people do you have to run this? The most frequently ignored question, and the one that most often kills a project. Even running a single Airflow instance well takes people. A two-person team that decides to self-operate all five layers finds itself, six months later, doing infrastructure work instead of data work.

The governance the original guide covers at the end is, in effect, the same story as question 6. Access control, ownership, PII lineage, and retention policy aren't something you buy as a tool — they're something people carry out, and the tool only makes carrying it out cheaper.

Conclusion — the Landscape Changes, But the Questions Remain

To sum up.

• Instead of picking a tool per layer, get the decision at that layer clear first, then pick the tool that fits that decision. The tool list changes every three years; the axis of decision doesn't.
• The table-format war has effectively ended with Iceberg v3 absorbing Delta's differentiating features. Real lock-in and governance have moved to the catalog layer, and catalog implementations still aren't uniform in what they support.
• Single-node engines have pulled a substantial share of cluster work back to the local machine. The line isn't data size itself — it's "does it fit on one machine" and "are multiple people doing it at once."
• The market is consolidating across layers. The Fivetran/dbt Labs merger is the signal, and the countermeasure is actually verifying whether a vendor really sits on open formats.
• Tool selection usually resolves within six questions. The last one — how many people will operate it — is the most frequently ignored.

A landscape map is useful, but memorizing the map and deciding on a route are different things. Before you next open a tool comparison chart, try writing, in one sentence, what decision you're actually making at that layer. If you can't write that sentence, the comparison chart won't help you.

References

• A Data Tooling Landscape Guide for Developers — GeekNews (2026-07-28, 51 points)
• Data Landscape Guide for Developers — original post
• Fivetran + dbt Labs merger completion press release (2026-06-01)
• Apache Iceberg — table spec
• Apache Iceberg — REST catalog Open API spec
• Databricks — Apache Iceberg v3 public preview announcement
• DuckLake — a lakehouse format that uses a SQL database as the catalog
• DuckDB release notes
• Iceberg v3 Row Lineage — Row IDs Aren't Stored in the File (related post)
• DuckDB Now Has a Client-Server Protocol (related post)
• After Airflow 2's EOL — the Real Task List from 2 to 3 (related post)
• PySpark 4.2 Makes Arrow UDFs the Default (related post)