Export a Database Table to Microsoft Fabric OneLake

Land operational data into Microsoft Fabric without hand-built scripts or fragile cron jobs. This blueprint extracts rows from a PostgreSQL database and uploads the result as a CSV file into a Microsoft Fabric Lakehouse through OneLake, giving you a repeatable database-to-Lakehouse ingestion path. It solves the common gap between a transactional database and the Fabric analytics layer: getting yesterday's records into a Lakehouse landing zone, partitioned by date, ready for Spark, notebooks, or SQL endpoints.

How it works

1. The extract task (io.kestra.plugin.jdbc.postgresql.CopyOut) runs a SQL query (SELECT * FROM orders WHERE created_at::date = current_date - 1) and writes the result to Kestra internal storage as a CSV with a header row (format: CSV, header: true).
2. The upload_to_onelake task (io.kestra.plugin.microsoft.fabric.onelake.Upload) takes that file from outputs.extract.uri and uploads it to the target Lakehouse, addressed by workspaceId and itemId (the Fabric workspace and Lakehouse GUIDs).
3. The destination filePath (raw/orders/{{ now() | dateFormat('yyyy-MM-dd') }}/orders.csv) builds a date-partitioned folder layout in OneLake so each run lands in its own dated path.
4. Connection details come from pluginDefaults for PostgreSQL, keeping the task definitions clean and reusable.

What you get

• A working database-to-OneLake CSV ingestion flow
• Date-partitioned file layout in the Lakehouse for clean Bronze-layer staging
• Credentials handled through Kestra secrets, not hardcoded values
• A uri output (the OneLake path) ready to chain into downstream Fabric jobs

Who it's for

• Data engineers building medallion (Bronze/Silver/Gold) pipelines in Microsoft Fabric
• Analytics teams moving operational data into a Lakehouse landing zone
• Platform teams standardizing database-to-Fabric ingestion patterns

Why orchestrate this with Kestra

Fabric pipelines and OneLake do not orchestrate your upstream databases. Kestra closes that gap: event-driven and scheduled triggers, automatic retries on transient failures, full execution lineage across the extract and upload steps, and a declarative YAML definition you can version and review. You get one place to coordinate the database query and the Fabric load, with visibility the Fabric scheduler alone cannot provide for external sources.

Prerequisites

• A Microsoft Fabric workspace and a Lakehouse, with their GUIDs
• A Microsoft Entra service principal with access to the Fabric workspace
• A reachable PostgreSQL database (adjust pluginDefaults for another JDBC source)

Secrets

• FABRIC_TENANT_ID: Entra tenant ID for the service principal
• FABRIC_CLIENT_ID: service principal application (client) ID
• FABRIC_CLIENT_SECRET: service principal client secret
• DB_PASSWORD: password for the PostgreSQL user

Quick start

1. Add FABRIC_TENANT_ID, FABRIC_CLIENT_ID, FABRIC_CLIENT_SECRET, and DB_PASSWORD as Kestra secrets.
2. Set the workspace_id and lakehouse_id variables to your Fabric GUIDs.
3. Update the PostgreSQL url, username, and database name in pluginDefaults.
4. Adjust the SQL query and filePath to match your table and partition strategy.
5. Run the flow and confirm the CSV lands in the Lakehouse Files/ area.

How to extend

• Swap CopyOut for another JDBC plugin (MySQL, SQL Server, Oracle) to source from a different database.
• Add a trigger so the export runs daily, or fires on an event from another flow.
• Chain a Fabric notebook or Spark job after the upload to transform the Bronze data into Silver.
• Parameterize the table name and partition keys with inputs to reuse the flow across datasets.

Links

• plugin-microsoft documentation
• Microsoft Fabric orchestration with Kestra