Azure, Databricks or Fabric? What Dutch Data Engineer Job Ads Actually Ask For

The Scenario: A Dutch Data Team Stuck Between Three Stacks

Picture a mid-sized Dutch organisation:

• Azure tenant already in place.
• A data lake in Azure Data Lake Storage Gen2.
• Legacy pipelines in Azure Data Factory and some SSIS packages lifted to Azure-SSIS Integration Runtime.
• A couple of Databricks workspaces running on Azure Databricks for advanced transformations.
• A BI team starting to experiment with Microsoft Fabric because Power BI Premium (or Fabric capacity) is already in use.

The team’s pain points:

• Job ads for new data engineers mention Azure Data Factory, Azure Synapse, Databricks, Fabric, Delta Lake, Power BI, SQL, Python, Spark in one breath.
• Management wants a “future-proof” platform choice, but projects keep mixing all three.
• Candidates are unsure whether to present themselves as “Azure engineer”, “Databricks engineer”, or “Fabric engineer”.

This is exactly the confusion reflected in current Dutch job ads: employers are not picking one stack; they’re converging on Azure as the base, plus one primary engine (Databricks or Fabric), and expecting familiarity with the rest.

What Dutch Azure Data Engineer Job Ads Actually Emphasise

Patterns you’ll see if you scan Dutch Azure data engineer skills and data engineer vacatures today:

1. Azure is the non‑negotiable foundation

Almost every data engineer role that mentions Databricks or Fabric also expects:

• Azure fundamentals: resource groups, VNets, private endpoints, managed identities, Key Vault, RBAC.
• Storage: Azure Data Lake Storage Gen2 (hierarchical namespace), Blob Storage, basic performance and cost considerations.
• Data movement/orchestration: Azure Data Factory or Synapse pipelines (copy activities, mapping data flows, triggers, integration runtimes).

Even Fabric-heavy roles assume:

• You understand how data lands in OneLake and how that relates to existing ADLS Gen2 setups.
• You can work with Microsoft Entra ID permissions and service principals.

In practice, job ads treat Azure as:

The platform you must be fluent in, regardless of whether your main engine is Databricks or Fabric.

2. Databricks shows up as the “serious engineering” engine

When a role leans towards Databricks, the description usually emphasises:

• Apache Spark: transformations over large datasets, partitioning, joins, performance tuning.
• Delta Lake: ACID transactions, schema evolution, time travel, MERGE operations.
• Python or Scala: notebooks, modular ETL code, tests.
• CI/CD: deploying notebooks/jobs via Azure DevOps or GitHub Actions.

These roles often mention Synapse or Data Factory only as orchestration or ingestion tools; the heavy lifting is expected in Databricks.

3. Fabric appears as the “end‑to‑end analytics” layer

Fabric is now visible in Dutch job ads, especially where Power BI is already central.

Patterns:

• Lakehouse and Warehouse: building models over OneLake, using Delta tables under the hood.
• Dataflows Gen2: ELT for medium-sized workloads, especially for self-service or semi-governed scenarios.
• Integration with Power BI: semantic models, Direct Lake, and governance via workspaces and domains.

Fabric-heavy roles are more common in BI/analytics engineering than back-end data engineering, but data engineer roles increasingly mention:

• “Experience with Fabric or willingness to learn Fabric”.
• “Ability to collaborate with BI teams using Fabric Lakehouse/Warehouse”.

4. SQL + scripting are still the core skills

Regardless of stack, job ads consistently ask for:

• Strong SQL: window functions, CTEs, incremental loads, data quality checks.
• Python (or sometimes Scala): for Spark, utilities, tests, and small automation tasks.

This matters because it’s the portable part of your profile: SQL + Python + data modelling show up across Azure, Databricks, and Fabric.

How the Three Stacks Actually Fit Together (Technically)

To decide where to specialise, it helps to be precise about how Azure, Databricks, and Fabric interact today.

Azure Data Platform Core

Typical components you’ll see in job ads and in our scenario:

• Azure Data Lake Storage Gen2: the main landing zone.
• Azure Data Factory or Synapse pipelines: ingestion, scheduling, simple transformations.
• Azure SQL Database / Azure Synapse dedicated SQL pool: structured stores for downstream systems.

Key behaviours (current as of late 2026):

• Data Factory/Synapse pipelines support both managed virtual network and self-hosted integration runtime for connectivity.
• Copy activities can move data between ADLS, SQL, SaaS sources, etc. with mapping data flows providing Spark-based transformations.

These services remain widely used in job ads as the orchestration layer even when Databricks or Fabric are the transformation engines.

Azure Databricks

Azure Databricks is:

• A first-party Azure service that provides managed Spark clusters and SQL warehouses.
• Integrated with Microsoft Entra ID for authentication and supports managed identities for some operations.

In our scenario, the team uses Databricks to:

• Read raw data from ADLS Gen2.
• Transform it into Delta Lake tables.
• Expose curated layers to downstream tools (Synapse, Power BI, Fabric connectors).

A minimal but realistic transformation pattern:

from pyspark.sql import SparkSession
from pyspark.sql.functions import col, year

spark = SparkSession.builder.getOrCreate()

# Read raw data from ADLS Gen2 (using a configured OAuth/managed identity)
raw_df = spark.read.parquet("abfss://raw@datalake.dfs.core.windows.net/sales/")

# Basic transformation: filter, add derived column
curated_df = (
    raw_df
    .filter(col("order_date") >= "2026-01-01")
    .withColumn("order_year", year(col("order_date")))
)

# Write curated data as Delta table
curated_df.write.format("delta").mode("overwrite").save(
    "abfss://curated@datalake.dfs.core.windows.net/sales_delta/"
)

This is the kind of work Databricks-heavy job ads expect you to be comfortable with: Spark, Delta Lake, and scalable transformations.

Microsoft Fabric

Fabric is built around OneLake, with engine experiences like:

• Lakehouse: Delta-based tables exposed via SQL and Spark.
• Warehouse: SQL-first experience over structured data.
• Dataflows Gen2: Power Query-based transformations running in Fabric.

In our scenario, the BI team starts consuming the curated Delta tables from Databricks through Fabric Lakehouse or Warehouse connectors, or by landing data directly in OneLake.

Key behaviours (current high-level, without version-specific detail):

• Fabric Lakehouse uses Delta tables as the storage format.
• Power BI can use Direct Lake for semantic models over Fabric Lakehouse/Warehouse when capacity and configuration allow, avoiding Import or DirectQuery latency.

Job ads mentioning Fabric typically expect you to:

• Understand how data is structured in Lakehouse/Warehouse.
• Design tables and partitions so BI workloads perform well.

Three Common Role Patterns in Dutch Job Ads

When you strip away buzzwords, most ads fall into three patterns.

Pattern 1: Azure‑Centric Data Engineer (Databricks as a plus)

Typical wording:

• “Azure data engineer with experience in Data Factory, Synapse, and Databricks.”

Core expectations:

• You can design and build ingestion pipelines in Data Factory/Synapse.
• You understand ADLS Gen2 structure (raw/curated layers, folder strategies).
• You can collaborate with Databricks specialists and read/write data they produce.

Focus your skills on:

• Robust ingestion and orchestration.
• Data modelling for SQL stores.
• Basic Spark/Databricks familiarity (enough not to be blocked).

Pattern 2: Databricks‑First Data Engineer (Azure as platform)

Typical wording:

• “Data engineer with strong Databricks and Delta Lake skills on Azure.”

Core expectations:

• You own the transformation layer in Databricks.
• You design Bronze/Silver/Gold layers in Delta Lake.
• You integrate with Azure Data Factory/Synapse for scheduling or upstream ingestion.

Focus your skills on:

• Spark performance and Delta Lake design.
• Testing, CI/CD, and deployment of Databricks jobs.
• Secure access to ADLS Gen2 via service principals/managed identities.

Pattern 3: Fabric‑Oriented Analytics Engineer (with Azure/Databricks awareness)

Typical wording:

• “Data/analytics engineer experienced with Power BI and Fabric Lakehouse.”

Core expectations:

• You build Lakehouse/Warehouse structures in Fabric.
• You understand how data arrives from Azure sources (Data Factory, Databricks, or direct connectors).
• You collaborate closely with BI developers.

Focus your skills on:

• Fabric Lakehouse/Warehouse table design.
• Dataflows Gen2 for medium-scale ETL.
• Semantic models and performance patterns (including Direct Lake where appropriate).

Applying This to Our Scenario: Before and After

Back to our Dutch data team.

Before:

• Pipelines split between Data Factory, Synapse, Databricks, and early Fabric experiments.
• No clear ownership: everyone is “sort of” doing everything.
• Job ads are vague: “Experience with Azure, Databricks, and Fabric is a plus.”

After aligning roles with patterns:

1. Azure‑centric engineer owns:

   • Ingestion from on‑prem and SaaS sources via Data Factory.
   • Landing data in ADLS Gen2 raw zone.
   • Orchestration of Databricks jobs and Fabric refreshes.

2. Databricks‑first engineer owns:

   • Transformations from raw to curated Delta tables.
   • Performance and reliability of Spark jobs.
   • Technical contracts for how curated data is exposed to Fabric and SQL.

3. Fabric‑oriented analytics engineer owns:

   • Lakehouse/Warehouse structures over curated data.
   • Models and Dataflows Gen2 for BI teams.
   • Data access patterns and governance in Fabric workspaces.

Job ads become more precise:

• One role emphasises Azure + orchestration.
• One emphasises Databricks + Delta Lake.
• One emphasises Fabric + Power BI, but all three mention Azure.

This mirrors what you see across many Dutch postings: employers want all three in the organisation, but each engineer has a primary strength.

How to Position Yourself in Dutch Job Ads

Given these patterns, your CV and LinkedIn profile should make one thing clear: your primary engine.

Step 1: Pick your main strength

• If you enjoy infrastructure, governance, and reliable ingestion → call yourself an Azure data engineer.
• If you enjoy large-scale transformations and performance tuning → call yourself a Databricks data engineer.
• If you enjoy modelling and analytics close to the BI layer → call yourself a Fabric/analytics engineer.

Step 2: Show the “other two” as supporting skills

In each case:

• Azure specialist: list “Databricks (collaboration, reading/writing Delta)” and “Basic Fabric (consuming from Lakehouse/Warehouse)”.
• Databricks specialist: list “Azure Data Factory/Synapse pipelines (orchestration)” and “Fabric consumption of curated Delta data”.
• Fabric specialist: list “Azure storage and pipelines” and “Databricks as upstream transformation engine”.

Step 3: Use language job ads recognise

Phrase your experience in ways that match common Dutch postings:

• “Designed and implemented ingestion pipelines in Azure Data Factory and Synapse pipelines.”
• “Built and maintained Delta Lake layers (Bronze/Silver/Gold) in Azure Databricks.”
• “Modelled data in Microsoft Fabric Lakehouse/Warehouse for Power BI semantic models.”

One Practical Takeaway: Choose a Primary Engine, Don’t Pick a Side

When you read data engineer vacatures that mention Azure, Databricks, and Fabric, don’t treat them as competing bets. They’re three layers of the same ecosystem.

The practical move is:

Pick one of Azure orchestration, Databricks transformations, or Fabric analytics as your primary strength, and build working familiarity with the other two.

That’s the skill profile Dutch employers are actually hiring: not “Azure vs Databricks vs Fabric”, but “Azure plus one main engine, plus the ability to collaborate across the rest of the stack.”