Category: Databricks

Databricks lakehouse platform tutorials: Delta Lake, Apache Spark, Unity Catalog, and MLflow for data engineering.

  • Databricks Unity Catalog + Apache Iceberg in 2026

    Databricks Unity Catalog + Apache Iceberg in 2026

    The table format question is settled. Apache Iceberg won. Snowflake, Databricks, AWS, Google, and every serious data platform has committed to it. What hasn’t settled — what’s actively being fought over right now, with real architectural consequences for every data team making lakehouse decisions — is the catalog question. And the catalog matters far more than the format.

    The catalog resolves metadata, controls access, vends credentials, sequences commits, and acts as the single API boundary between every engine and every byte of data your organization owns. Pick the wrong one and you inherit operational debt that grows with each table you add. At Data + AI Summit 2026, Databricks made its position clear: Unity Catalog is the most comprehensive and open catalog across both the Delta Lake and Apache Iceberg ecosystems — with Managed Iceberg GA, Iceberg v3 GA, cross-engine ABAC, and new federation connectors including Snowflake Horizon and Salesforce Data Cloud.

    This is the guide that breaks down what Unity Catalog actually does for Iceberg workloads in 2026 — not the keynote version, but the one that tells you which features are GA, which are preview, what the access model looks like, and where the edges still are.

    TL;DR

    → Unity Catalog now governs both Delta Lake and Apache Iceberg tables from a single catalog. Managed Delta tables are GA. Managed Iceberg tables are in Public Preview (available on Databricks Runtime 16.4 LTS and above).

    → External engines access Unity Catalog managed tables through two open APIs: the Unity REST API (read/write/create for Delta clients) and the Iceberg REST Catalog (IRC) (read/write/create for Iceberg clients). Both support credential vending — temporary, scoped credentials that inherit the requesting principal’s privileges.

    → Iceberg clients that can write to Unity Catalog managed tables: Apache Spark, Apache Flink, Trino, and Snowflake. Path-based access to managed tables is not supported — it bypasses access controls and breaks managed table features.

    → Lakehouse Federation lets Unity Catalog govern tables in foreign catalogs: AWS Glue, Hive Metastore, Snowflake Horizon, Salesforce Data Cloud, Google Cloud Lakehouse, and Palantir. For Snowflake-managed Iceberg tables specifically, Catalog Federation reads directly from object storage (Databricks compute only, no Snowflake compute billed). Non-Iceberg Snowflake tables fall back to Query Federation.

    → Cross-engine ABAC is now GA: column masks and row filters enforced during server-side scan planning through the Iceberg REST Scan APIs. Any engine implementing the Iceberg 1.11 scan-planning client gets the same policies applied without a Databricks runtime.

    → A new FILE type (beta) lets managed Delta and Iceberg tables natively govern unstructured data — PDFs, images, audio, video — in open formats, tracked in Unity Catalog alongside structured tables.

    Why the catalog became the battleground

    Diagram showing how external engines like Apache Spark, Trino, and Snowflake access Unity Catalog managed tables via Unity and Iceberg REST APIs, with cloud object storage managed by Unity Catalog.

    Unity Catalog governs both table formats through one metadata layer. Policies enforce at scan-planning time — before any data file is read — so governance travels with the catalog, not the engine.

    When Delta Lake launched, the catalog was a formality. A Hive Metastore tracked table locations and schemas, and the format handled everything interesting. With Iceberg winning as the shared format, the catalog became the differentiator. Every engine can read Iceberg. The question is which engine decides who can read it, what they can see within each table, and how commits are sequenced when multiple engines write concurrently.

    That’s what Unity Catalog answers for Databricks workloads. It sits between every engine and every table, enforcing access policies at the point where scan planning happens — before any data file is read. Because the Iceberg REST Catalog API exposes those policies at the server-side scan-planning layer, a compliant engine (Spark, Trino, DuckDB via the Iceberg 1.11 client) receives the same row filters and column masks that a Databricks notebook would see, without needing to run inside Databricks. The governance travels with the catalog, not with the runtime.

    Managed tables: what Unity Catalog controls

    The key distinction in Unity Catalog is between managed and external tables. Managed tables are the default and recommended type. Unity Catalog owns everything: where the data files live, how they’re organized, compaction, statistics, optimization. You reference tables by three-part name (catalog.schema.table). Path-based access is explicitly not supported for managed tables — it bypasses Unity Catalog’s access controls and breaks features like Predictive Optimization and Liquid Clustering.

    Managed Delta tables (GA) — Unity Catalog’s default. The Delta format with ACID transactions, schema evolution, and Databricks-specific optimizations. External engines access them read-only through the Unity REST API or as Iceberg via UniForm (Delta tables exposed with an Iceberg read layer). Write access for external Delta clients is in Public Preview.

    Managed Iceberg tables (Public Preview, Databricks Runtime 16.4+) — native Apache Iceberg tables owned by Unity Catalog. External engines with Iceberg REST Catalog support can read, write, and create managed Iceberg tables. Supported write clients today: Apache Spark, Apache Flink, Trino, and Snowflake. Predictive Optimization and Liquid Clustering apply automatically.

    The practical implication: if your workload needs Snowflake to write data that Databricks then transforms, managed Iceberg is the architecture — Snowflake connects via the Iceberg REST Catalog, writes to the managed table, and Databricks reads with full governance. If the flow is Databricks-to-Snowflake reads only, UniForm on a managed Delta table is simpler than standing up a separate managed Iceberg table.

    Cross-engine access: the two APIs

    Unity REST API — for Delta Lake clients. Provides read and write access to managed and external Delta tables. Both modes support credential vending: Unity Catalog issues temporary credentials scoped to the requesting principal’s privileges, so external engines never hold long-lived Databricks credentials and governance policies apply at the storage layer.

    Iceberg REST Catalog (IRC) — for Iceberg clients. Read/write/create access to managed Iceberg tables; read-only access to Delta tables with Iceberg reads enabled (UniForm). The credential vending model is the same: temporary, scoped, inheriting the requesting principal’s privileges from Unity Catalog’s access control list.

    Both APIs hit the Unity Catalog server, not object storage directly. That’s what makes policy enforcement possible at the catalog level rather than being a layer each engine has to implement independently.

    Lakehouse Federation: governing tables you don’t own

    Unity Catalog’s federation model extends governance to tables in foreign catalogs — systems outside Databricks that Unity Catalog can query and, in some cases, govern. The federated catalog list as of mid-2026: AWS Glue, Snowflake Horizon, Hive Metastore, Salesforce Data Cloud, Google Cloud Lakehouse, and Palantir.

    The Snowflake federation case has a meaningful internal split worth understanding separately:

    Catalog Federation (for Snowflake-managed Iceberg tables) — Unity Catalog reads Snowflake Iceberg tables directly from cloud object storage. Databricks compute executes the query; Snowflake compute is never invoked, so there is no Snowflake credit charge for the read.

    Query Federation (for native Snowflake tables) — Non-Iceberg Snowflake tables are always accessed via Query Federation. Unity Catalog sends a query to Snowflake’s compute, which runs it and returns the result. Snowflake credits fire. The distinction is the same split as Salesforce Data Cloud’s File vs Query Federation — the Iceberg format is what enables compute-free storage-layer reads across both platforms.

    Cross-engine ABAC: governance that travels with the catalog

    Cross-engine ABAC is now GA: column masks and row filters defined in Unity Catalog are enforced during server-side scan planning through the Iceberg REST Scan APIs. Any engine that implements the Iceberg 1.11 scan-planning client — Spark, DuckDB, Trino, any compliant engine — gets those policies applied before it reads a single data file.

    Traditional column masking was enforced at query execution time, inside the compute layer. An engine that bypassed the query layer and read files directly could skip the masks. Server-side scan planning enforcement moves the policy check to the catalog, so an Iceberg-compliant client gets an already-filtered manifest — it can only see the files and columns it’s allowed to see, and the catalog decided that before any compute ran.

    Predictive Optimization and Liquid Clustering

    Predictive Optimization automatically identifies tables that need compaction, clustering, or statistics updates based on workload patterns and applies those operations proactively. For managed Iceberg tables, this means the same performance tuning Databricks applies to Delta workloads now runs on open-format tables accessed by external engines.

    Liquid Clustering replaces the manual partition-column decision with an adaptive co-location scheme: you specify clustering keys, and Unity Catalog reorganizes files continuously based on actual query patterns. For Iceberg tables read by Snowflake or Trino, this means better file pruning and lower scan costs even without partition-level optimization on the reader side.

    The gotchas nobody warns you about

    Managed Iceberg tables are Public Preview, not GA. Production workloads should track the GA release — preview status means the API can change.

    Path-based access breaks managed table features. If an external tool or legacy process accesses managed table files directly by path, it bypasses access controls and disables Predictive Optimization and Liquid Clustering. The migration from external tables to managed tables requires updating every access pattern to use three-part names and the catalog APIs.

    Snowflake Catalog Federation requires Iceberg-backed Snowflake tables. The compute-free federation path only works for Snowflake-managed Iceberg tables. Native Snowflake tables fall back to Query Federation with Snowflake compute charges on every federated read.

    Foreign table metadata freshness. For federated tables from Snowflake or other external catalogs, Unity Catalog caches metadata. Tables updated frequently in the external system may appear stale until a metadata refresh runs. For high-frequency foreign tables, configure periodic refresh via Lakeflow jobs.

    The Iceberg v4 roadmap changes the file structure. Databricks engineers are actively proposing Iceberg v4 changes: an adaptive metadata tree (most operations write a single file), relative path support, and a modernized statistics model for VARIANT and GEOMETRY types. Architectures built on Unity Catalog now are well-positioned for v4 because the catalog abstracts format evolution.

    The one principle

    The catalog is a write-path decision, not a read-path one. Any engine can read Iceberg. The question is which catalog controls who writes, how commits are sequenced, and which policies apply at scan time. Unity Catalog’s answer — two open APIs, credential vending, server-side ABAC, foreign catalog federation — is coherent and production-ready for Iceberg workloads today, with managed Iceberg tables a quarter behind on GA. Choose your catalog before you choose your partition strategy, because the catalog is the layer that makes your governance durable as you add engines.

    Related reading: What’s new with Unity Catalog at Data + AI Summit 2026 · Unity Catalog managed tables docs · The 2026 Migration Trap: Native Tables to Dynamic Iceberg v3 · Governing the AI Agent: Snowflake CoCo + MCP Security

  • Delta Lake vs Apache Iceberg — Why I Chose Iceberg for Our Data Lakehouse

    Delta Lake vs Apache Iceberg — Why I Chose Iceberg for Our Data Lakehouse

    TL;DR
    → Delta Lake is easier to start with, especially if you’re already on Databricks
    → Iceberg wins on engine flexibility — works natively with Spark, Flink, Trino, Snowflake, and more without custom connectors
    → Delta Lake’s vendor coupling with Databricks is a real cost if you’re multi-cloud or multi-engine
    → Iceberg’s partition evolution lets you change partition schemes without rewriting data — that feature alone saved us a full weekend of migration work
    → Migration from Delta to Iceberg is harder than most blog posts suggest — budget four to eight weeks, not a weekend
    → If you’re greenfield, start with Iceberg. If Delta is working, don’t migrate until you hit a specific limit


    I didn’t choose Iceberg because I read a benchmark blog post. I chose it after six months of hitting Delta Lake’s limits in ways that weren’t obvious until they were expensive.

    We were running a mid-sized data lakehouse — S3-backed, Spark for processing, Snowflake for consumption, dbt for transformation. Delta Lake was the default choice. Everyone on the team had used it before. The documentation was solid. It worked — until it didn’t.

    This isn’t a “here are the specs” comparison. You can get that from the docs. This is what actually happened when I ran both in production, why I made the switch, and what I’d tell you before you pick one.


    What We Were Actually Trying to Solve

    Before I get into the comparison, context matters. Our stack at the time: raw data landing in S3, Apache Spark for heavy transformation, Snowflake as the consumption layer for analysts, dbt for modeling, and Apache Airflow for orchestration.

    We needed ACID transactions on S3, time travel for debugging, and the ability to do incremental loads without full partition rewrites. Delta Lake checked all those boxes — initially. The problems showed up at scale and at the edges.


    Where Delta Lake Started Hurting Us

    Engine Lock-In Was a Real Problem

    Delta Lake works great if Spark is your only compute engine. The moment we tried to query Delta tables directly from Snowflake or Trino, things got complicated. Delta’s transaction log format is proprietary. You need the Delta connector — and not every engine has a first-class one.

    We wanted analysts to query raw lakehouse tables directly from Snowflake without going through Spark first. With Delta, that required Snowflake’s Delta Sharing integration, which had limitations on what operations were supported. It wasn’t broken, but it added friction and another dependency to manage.

    Apache Iceberg solves this cleanly. The table format is open. Snowflake, Spark, Flink, Trino, Athena, Dremio — they all read and write Iceberg natively. No connectors to manage. No format translation layer.

    Partition Management Was Getting Messy

    With Delta Lake, partitioning decisions are set at table creation. Changing a partition scheme means rewriting the table. At 100M+ rows, that’s not a quick operation.

    We had a table partitioned by event_date. Six months in, query patterns changed — analysts were filtering by event_date and region together. Repartitioning meant a full backfill job over a weekend, plus repointing all downstream dbt models.I wrote about a similar pain point in the problem with dbt incremental models — the pattern is the same.

    Iceberg’s partition evolution lets you change the partition spec without rewriting data. Old data stays as-is. New data uses the new scheme. Queries still work against both.

    Hidden Partitioning Changed How We Design Tables

    Iceberg supports hidden partitioning — you define partition transforms like days(event_timestamp) or bucket(user_id, 16) and Iceberg handles physical partitioning transparently. Your queries don’t need to know about partition columns. The engine prunes automatically.

    With Delta Lake, you need to explicitly filter on partition columns or you’ll scan everything. That’s fine when everyone knows the rules. It’s a problem when a new analyst writes a query without knowing which columns are partition keys.


    Where Delta Lake Is Still Better

    If you’re on Databricks, stay on Delta. The integration is tight, the tooling is mature, and Databricks has invested heavily in Delta’s performance.. Liquid Clustering makes partition management much more flexible. If Databricks is your primary compute layer, switching to Iceberg gives you marginal benefit for non-trivial migration cost.

    Delta’s MERGE performance on Spark is excellent. For high-frequency CDC workloads where you’re doing upserts at scale on Spark, Delta’s MERGE implementation is well-optimised. Iceberg’s MERGE has improved significantly but Delta still has an edge in some Spark-specific CDC patterns.

    Delta has simpler operational overhead for small teams. Delta’s transaction log is easier to reason about. The tooling for vacuum, optimize, and Z-ordering is well-documented and predictable.


    The Comparison You Actually Need

    Feature Delta Lake Apache Iceberg
    Engine supportSpark-native; connectors for othersTruly multi-engine (Spark, Flink, Trino, Snowflake, Athena)
    Partition evolutionRequires full table rewriteSchema-safe, no data rewrite needed
    Hidden partitioningNot supportedSupported — engines auto-prune
    MERGE / CDC performanceExcellent on SparkStrong, improving; slightly behind Delta on Spark CDC
    Vendor alignmentDatabricks ecosystemVendor-neutral, Apache foundation
    Operational toolingMature, well-documentedMaturing fast; strong in 2024–2025
    Multi-cloud flexibilityPossible but frictionFirst-class support across clouds
    Migration effortN/A (starting point)Non-trivial; plan 4–8 weeks

    THE MIGRATION: WHAT IT ACTUALLY COST US

    The Migration: What It Actually Cost Us

    I’ll be direct: the migration was harder than I expected. If you’ve read my piece on automation in data engineering, you’ll recognise the pattern — the technical part is rarely the hard part. It’s the downstream work nobody accounts for.

    The core work wasn’t the data conversion — we used the delta-iceberg migration utility and it handled most of the heavy lifting. The harder parts were everything else.

    Downstream dependency mapping.

     Every dbt model, every Airflow DAG, every Spark job that referenced a Delta table path needed updating. We had 40+ models. Two had hardcoded partition paths we didn’t catch until QA.

    Metadata catalog updates.

     We use AWS Glue Data Catalog. Every table needed its metadata updated to reflect the Iceberg format. Glue’s Iceberg support has improved, but it’s not frictionless.

    Testing the rollback plan. We kept Delta tables live for 30 days post-migration with a cutover switch in Airflow. That meant double-writing during the transition window — additional storage cost and added pipeline complexity.

    ⚠️ The migration trap: The data conversion tooling works. What catches teams off guard is the downstream mapping work — every pipeline, model, and job that references a table path. Budget more time for that than for the actual format conversion.

    Total elapsed time: six weeks. Two engineers. Not a weekend project.


    When to Choose Delta Lake

    • Your primary compute layer is Databricks
    • You’re a small team that wants simpler operations
    • You’re doing high-frequency CDC on Spark
    • You’re early stage — get something working first

    When to Choose Iceberg

    • You’re running multiple query engines (Spark + Snowflake, Trino + Flink)
    • You need partition evolution without full table rewrites
    • You’re building a vendor-neutral architecture
    • Your analysts query the lakehouse directly from Snowflake

    What I’d Do Differently

    Start with Iceberg if you’re greenfield. The setup is slightly more involved, but you avoid the migration cost entirely. The ecosystem has matured enough in 2024-2025 that “Iceberg is less mature” is no longer a strong argument.

    If you’re already on Delta and it’s working — don’t migrate for the sake of it. Migrate when you hit a specific limit: engine lock-in, partition inflexibility, or multi-cloud requirements.

    And if you do migrate, don’t underestimate the downstream mapping work. The data conversion is the easy part.


    Frequently Asked Questions

    What is the main difference between Delta Lake and Apache Iceberg?

    Delta Lake is a table format developed by Databricks, optimised for Spark workloads with strong Databricks integration. Apache Iceberg is an open table format designed for multi-engine environments — it works natively with Spark, Flink, Trino, Snowflake, and Athena without custom connectors. The core difference is engine flexibility.

    Is Apache Iceberg better than Delta Lake?

    It depends on your stack. Iceberg is better if you’re running multiple query engines or building a vendor-neutral architecture. Delta Lake is better if Databricks is your primary compute layer. Neither format is objectively superior.

    Can Snowflake read Delta Lake tables?

    Yes, through Delta Sharing or Snowflake’s Delta connector — but with limitations. Snowflake reads Iceberg tables natively as a first-class citizen, which is why multi-engine stacks tend to favour Iceberg.

    How hard is it to migrate from Delta Lake to Apache Iceberg?

    Harder than most blog posts suggest. The data conversion tooling handles the format migration, but remapping downstream pipelines, updating metadata catalogs, and testing rollback scenarios adds significant effort. Budget four to eight weeks for a production migration with 30–50 tables.

    Does dbt support Apache Iceberg?

    Yes. dbt supports Iceberg through the Spark and Athena adapters, and Snowflake’s Iceberg table support works with dbt models running on Snowflake. Production-ready as of 2024.

    What is hidden partitioning in Apache Iceberg?

    Hidden partitioning lets Iceberg manage partition logic transparently. You define partition transforms like days(event_timestamp) at the table level, and Iceberg handles physical file organisation and query pruning automatically — no need to filter on partition columns explicitly.

  • The Problem with Data Engineering Certifications That Nobody Talks About

    The Problem with Data Engineering Certifications That Nobody Talks About

    I passed the SnowPro Gen AI certification not too long ago. Within the same week I was back at my desk staring at a broken pipeline that no multiple-choice question had ever prepared me for. The cert looked great on my profile. It fixed exactly nothing about the actual problem in front of me.

    I’m not saying certifications are worthless. I’m saying the industry has developed a quietly dishonest relationship with them — one where vendors, hiring managers, and candidates all play along with a fiction that a passed exam means something it doesn’t. Nobody wants to be the one to say it out loud.

    So I will. Let me be direct about what’s actually going on.


    TL;DR

    • Certifications test what vendors want you to know about their products — not whether you can actually engineer data systems that work under real conditions
    • The exam content is often months or years behind the tools you’ll actually use in production
    • Hiring managers use certs as a filter because it’s easy — not because it’s accurate
    • You can pass most data engineering certs with two weeks of practice exams and zero production experience
    • The real signal employers should care about — and rarely do — is what you’ve built, what broke, and what you learned from it
    • Certifications have a specific, narrow value: they are a vocabulary test, not a competence test. Know what you’re paying for

    WHAT CERTIFICATIONS ACTUALLY TEST

    Let’s start with what’s literally on the exam. Take the Databricks Certified Data Engineer Associate . The exam covers Delta Lake concepts, basic Spark operations, Unity Catalog, Databricks workflows. Good things to know.

    But the exam tests your ability to identify the correct answer from four options in a controlled environment. It does not test whether you can debug a production Spark job that’s been running for six hours and slowly consuming memory. It doesn’t test whether you can diagnose why a Delta merge is creating file fragmentation degrading query performance. It doesn’t test whether you can architect a pipeline that recovers gracefully when an upstream API starts returning malformed JSON at 3am.

    Those are the problems data engineers actually face. None of them are in the certification.

    A certification tells you that someone understood the conceptual framework of a product well enough to pass a vendor-designed exam. It tells you almost nothing about their ability to operate that product under adversarial conditions. And production is always adversarial.

    This gap exists in the AWS Certified Data Engineer Associate ,the Google Professional Data Engineer ,the Azure Data Engineer Associate ,and every dbt or Snowflake certification available. They all test the vendor’s idealised scenario.

    Real pipelines are never idealised.


    THE VENDOR INCENTIVE PROBLEM

    Who designs these exams? The vendors. Who benefits when thousands of engineers study for, pay for, and pass these exams? The vendors. Certification programmes are not primarily educational products. They are marketing products that create a credentialled user base and deepen platform lock-in.

    When Snowflake designs its certification exams ,the goal is not to produce engineers who can evaluate whether Snowflake is the right tool. The goal is to produce engineers deeply familiar with Snowflake’s architecture, syntax, and product positioning — engineers who will advocate for Snowflake when tooling decisions come up at their company.

    The exam content is shaped by commercial interest, not by what data engineers actually need to know. The practical consequence: certifications optimise for breadth of product knowledge over depth of engineering judgment. You learn feature names, service limits, and recommended architectures. You don’t develop the instinct that tells you something is going to break before it breaks.


    THE HIRING MANAGER TRAP

    I’ve sat in hiring discussions where a candidate without certifications was dismissed faster than one with a string of logos after their name, despite the uncertified candidate having a demonstrably stronger GitHub portfolio and much more interesting answers about production incidents they’d owned.

    Certifications persist in job postings because they’re easy to verify and hard to argue with. A cert is binary. Either you have it or you don’t. Technical judgment, architecture instinct, debugging ability — these require effort to assess.

    ⚠️ The signal problem: If you can pass a data engineering certification with two weeks of practice exams and no production experience — and you can — then having the certification tells an interviewer almost nothing about whether you can do the job. It tells them you can study for a test. That’s useful. But it’s not the same thing.

    The engineers most dismissive of certifications are often the most experienced. The engineers who lean most heavily on cert lists are often the ones who haven’t done enough production work to know what the gap actually looks like.


    THE STALE CONTENT PROBLEM

    Data engineering moves fast. The tooling landscape in 2024 looks materially different from 2021. dbt Core has changed substantially. Apache Iceberg has gone from niche to mainstream. Lakehouse architecture has shifted from concept to default.

    Certification exams do not move at this speed. Exam content is updated infrequently — sometimes annually, sometimes less. You can hold an AWS Data Engineer cert that emphasises EMR and Glue in patterns most teams have replaced with more modern tooling. You can hold a Databricks cert that doesn’t reflect how Unity Catalog has fundamentally changed governance.

    The cert is not wrong. It’s just dated. And dated knowledge in data engineering isn’t neutral — it can actively mislead you about how things should be built.

    I wrote about a related version of this in “Why I Stopped Using Snowflake Tasks for Orchestration” — official documentation and certification content often lags behind what practitioners have already learned through trial and error in production.


    WHAT YOU ACTUALLY LEARN WHEN YOU STUDY FOR A CERT

    Here’s the part I want to be fair about. Studying for a data engineering certification isn’t worthless. It’s just worth something different from what most people think.

    When you study for the Google Professional Data Engineer exam, you learn the GCP data ecosystem — BigQuery, Dataflow, Pub/Sub, Cloud Composer, Dataproc — in a structured way. You develop a vocabulary. You understand how services relate to each other.

    What it doesn’t give you is judgment. Judgment about when to use Dataflow versus Dataproc. When BigQuery’s cost model makes it the wrong tool despite its performance. When a simple Cloud Function is a better answer than a fully orchestrated pipeline.

    The honest framing: a certification is a vocabulary test with a structured curriculum. If you’ve never worked on a platform and need to get up to speed quickly, studying for the cert is efficient. If you already have production experience, the cert adds limited signal beyond what’s already on your resume.


    THE PRACTICE EXAM LOOPHOLE NOBODY WANTS TO DISCUSS

    Most data engineering certifications can be passed with aggressive practice exam grinding and minimal practical experience. Platforms like Udemy , Whizlabs and ExamTopics sell practice exam bundles close enough to real questions that a disciplined studier can reverse-engineer most of the exam in two to three weeks.

    I’ve seen candidates with zero Snowflake production experience pass the SnowPro Core exam in a week of evening study. I’ve seen engineers memorise their way through the AWS Data Engineer Associate without writing a single Glue job. The credential is indistinguishable from someone who earned it through genuine depth.

    The vendors know this. They update exam content periodically to counter braindump culture, but it’s an arms race they’re perpetually losing.


    WHAT ACTUALLY SIGNALS ENGINEERING COMPETENCE

    If I’m hiring a data engineer, here’s what I actually want to see.

    Tell me about a pipeline that broke in production. Not a hypothetical. What broke, how you found out, what the root cause was, how you fixed it, what you changed to prevent recurrence. This conversation reveals more engineering judgment than any certification.

    Show me something you built. A GitHub repo .A dbt project. A pipeline architecture diagram with a written explanation. The work I’ve been documenting — from the problem with dbt incremental models to Snowflake zero-copy cloning gotchas — is far more useful signal than any certification I hold.

    Tell me about a technical decision you disagreed with. Engineering judgment includes knowing when to push back, when to compromise, how to argue for a position with evidence. No cert tests this.

    Walk me through how you’d approach this problem. Give them a real scenario — a data quality issue, a cost spike, a schema migration in a live system. Watch how they think, not just what they know.

    The gap between what certifications measure and what engineering competence looks like is large enough that I’d rather see zero certifications with a detailed post-mortem of a real incident than four certs with nothing to show for the work.


    WHEN CERTIFICATIONS ARE ACTUALLY WORTH PURSUING

    You’re breaking into the field. If you’re transitioning into data engineering, certifications serve a genuine purpose. They give you structured curriculum and a credential that signals seriousness to employers who don’t yet have anything else to evaluate you on.

    Your employer requires it. Many enterprise organisations and consulting firms have vendor partnership requirements mandating certified staff levels. In that case, the cert has real organisational value regardless of signal quality.

    You’re learning a new platform systematically. Using cert study as structured onboarding to a new tool is legitimate. The curriculum forces breadth coverage self-directed learning often misses. Just know that completing the cert doesn’t mean you know how to use the platform well.

    You’re in a market where it’s table stakes. In some geographies and sectors, certain certs are required to get an interview. Clear the gate, then demonstrate real depth in the room.

    The certification isn’t the problem. The mythology around it is. The idea that passing the exam means you can build reliable data systems — that’s the fiction that causes real damage.


    WHAT THE INDUSTRY SHOULD DO INSTEAD

    Portfolio-based evaluation. A documented data engineering project — architecture decisions, tradeoffs, failures encountered — tells a hiring team far more than an exam score. GitHub already supports this.

    Incident post-mortems as credentials. A well-written post-mortem demonstrates debugging methodology, systems thinking, and the ability to learn from failure. No certification tests these.

    Practical assessments over multiple choice. The Databricks Data Engineer Professional is harder than most — it has a coding component requiring actual proficiency. More exams should work this way.

    Open curriculum from neutral sources. The Data Engineering Handbook and open-source community resources are doing more for actual engineering capability than most vendor certification programmes.


    FREQUENTLY ASKED QUESTIONS

    Are data engineering certifications worth it in 2024?
    It depends on where you are in your career. For someone entering the field, certs provide structured curriculum and a credential that signals seriousness. For experienced engineers, your production track record carries far more weight with strong technical hiring teams. Certs are worth what they cost if you understand what they are: a vocabulary test, not a competence test.

    Which data engineering certification is the most respected?
    Among practitioners, the Databricks Data Engineer Professional is generally seen as harder and more meaningful because it includes a practical component. Google Professional Data Engineer has strong enterprise name recognition. AWS Certified Data Engineer Associate is widely recognised in cloud-native teams. But respected by whom matters — strong engineering teams care less about cert logos than about demonstrated ability.

    Can you become a data engineer without certifications?
    Absolutely. Many strong data engineers have no certifications at all. A track record of real work — systems built, incidents resolved, architectural decisions owned — is equally or more compelling to technical hiring teams worth impressing.

    How long does it take to pass data engineering certification exams?
    Most candidates report 2–6 weeks of focused study. With aggressive practice exam preparation, some pass in under two weeks — which is part of what makes the credentials less meaningful than they appear.

    Do data engineering certifications expire?
    Yes. AWS certifications expire after three years, Google Cloud after two, Databricks varies by level. Recertification tends to be easier than initial certification and often doesn’t reflect how dramatically the tooling has evolved.

    What should a data engineering portfolio include instead of certifications?
    End-to-end pipeline projects with documented architecture decisions. Written post-mortems of production incidents. Data quality testing approaches. dbt projects with meaningful transformation logic. Cost analyses or performance optimisations from real environments. Anything that shows how you think, not just what tools you’ve touched.


  • Build a Databricks AI Agent with GPT-5

    Build a Databricks AI Agent with GPT-5

    The age of AI chatbots is evolving into the era of AI doers. Instead of just answering questions, modern AI can now execute tasks, interact with systems, and solve multi-step problems. At the forefront of this revolution on the Databricks platform is the Mosaic AI Agent Framework.

    This guide will walk you through building your first Databricks AI Agent—a powerful assistant that can understand natural language, inspect your data, and execute Spark SQL queries for you, all powered by the latest GPT-5 model.

    What is a Databricks AI Agent?

    A Databricks AI Agent is an autonomous system you create using the Mosaic AI Agent Framework. It leverages a powerful Large Language Model (LLM) as its “brain” to reason and make decisions. You equip this brain with a set of “tools” (custom Python functions) that allow it to interact with the Databricks environment.

    A diagram showing a Databricks Agent. A user prompt goes to an LLM brain (GPT-5), which then connects to tools (Python functions) and a Spark engine. Arrows indicate the flow between components.

    The agent works in a loop:

    1. Reason: Based on your goal, the LLM decides which tool is needed.
    2. Act: The agent executes the chosen Python function.
    3. Observe: It analyzes the result of that function.
    4. Repeat: It continues this process until it has achieved the final objective.

    Our Project: The “Data Analyst” Agent

    We will build an agent whose goal is to answer data questions from a non-technical user. To do this, it will need two primary tools:

    • A tool to get the schema of a table (get_table_schema).
    • A tool to execute a Spark SQL query and return the result (run_spark_sql).

    Let’s start building in a Databricks Notebook.

    Step 1: Setting Up Your Tools (Python Functions)

    An agent’s capabilities are defined by its tools. In Databricks, these are simply Python functions. Let’s define the two functions our agent needs to do its job.

    # Tool #1: A function to get the DDL schema of a table
    def get_table_schema(table_name: str) -> str:
        """
        Returns the DDL schema for a given Spark table name.
        This helps the agent understand the table structure before writing a query.
        """
        try:
            ddl_result = spark.sql(f"SHOW CREATE TABLE {table_name}").first()[0]
            return ddl_result
        except Exception as e:
            return f"Error: Could not retrieve schema for table {table_name}. Reason: {e}"
    
    # Tool #2: A function to execute a Spark SQL query and return the result as a string
    def run_spark_sql(query: str) -> str:
        """
        Executes a Spark SQL query and returns the result.
        This is the agent's primary tool for interacting with data.
        """
        try:
            result_df = spark.sql(query)
            # Convert the result to a string format for the LLM to understand
            return result_df.toPandas().to_string()
        except Exception as e:
            return f"Error: Failed to execute query. Reason: {e}"

    Step 2: Assembling Your Databricks AI Agent

    With our tools defined, we can now use the Mosaic AI Agent Framework to create our agent. This involves importing the Agent class, providing our tools, and selecting an LLM from Model Serving.

    For this example, we’ll use the newly available openai/gpt-5 model endpoint.

    from databricks_agents import Agent
    
    # Define the instructions for the agent's "brain"
    # This prompt guides the agent on how to behave and use its tools
    agent_instructions = """
    You are a world-class data analyst. Your goal is to answer user questions by querying data in Spark.
    
    Here is your plan:
    1.  First, you MUST use the `get_table_schema` tool to understand the columns of the table the user mentions. Do not guess column names.
    2.  After you have the schema, formulate a Spark SQL query to answer the user's question.
    3.  Execute the query using the `run_spark_sql` tool.
    4.  Finally, analyze the result from the query and provide a clear, natural language answer to the user. Do not just return the raw data table. Summarize the findings.
    """
    
    # Create the agent instance
    data_analyst_agent = Agent(
        model="endpoints:/openai-gpt-5", # Using a Databricks Model Serving endpoint for GPT-5
        tools=[get_table_schema, run_spark_sql],
        instructions=agent_instructions
    )

    Step 3: Interacting with Your Agent

    Your Databricks AI Agent is now ready. You can interact with it using the .run() method, providing your question as the input.

    Let’s use the common samples.nyctaxi.trips table.

    # Let's ask our new agent a question
    user_question = "What were the average trip distances for trips paid with cash vs. credit card? Use the samples.nyctaxi.trips table."
    
    # Run the agent and get the final answer
    final_answer = data_analyst_agent.run(user_question)
    
    print(final_answer)

    What Happens Behind the Scenes:

    1. Reason: The agent reads your prompt. It knows it needs to find average trip distances from the samples.nyctaxi.trips table but first needs the schema. It decides to use the get_table_schema tool.
    2. Act: It calls get_table_schema('samples.nyctaxi.trips').
    3. Observe: It receives the table schema and sees columns like trip_distance and payment_type.
    4. Reason: Now it has the schema. It formulates a Spark SQL query like SELECT payment_type, AVG(trip_distance) FROM samples.nyctaxi.trips GROUP BY payment_type. It decides to use the run_spark_sql tool.
    5. Act: It calls run_spark_sql(...) with the generated query.
    6. Observe: It receives the query result as a string (e.g., a small table showing payment types and average distances).
    7. Reason: It has the data. Its final instruction is to summarize the findings.
    8. Final Answer: It generates and returns a human-readable response like: “Based on the data, the average trip distance for trips paid with a credit card was 2.95 miles, while cash-paid trips had an average distance of 2.78 miles.”

    Conclusion: Your Gateway to Autonomous Data Tasks

    Congratulations! You’ve just built a functional Databricks AI Agent. This simple text-to-SQL prototype is just the beginning. By creating more sophisticated tools, you can build agents that perform data quality checks, manage ETL pipelines, or even automate MLOps workflows, all through natural language commands on the Databricks platform.