Data platforms · AI engineering
Technical Lead Data Engineer

AI amplifies judgment. The engineer is the edge.

I lead enterprise data platforms and build AI workflows that run inside real business systems, with controls on what they may do. Day to day, that is the Databricks platform of a global logistics company.

Email Teams Power BI Web Fabric Wrike Databricks GitLab ROUX THE EDGE

The routine runs on its own. Architecture and release decisions stay with me.

650
tables
~700
GB / weekday
900+
configured loads
1 019
steps in one unattended AI run

Platform figures updated September 2026. A step is one AI reply or one tool call; a run is the stretch between two of my messages. Runs are logged and verified. Spending money, publishing and deleting stay approval-gated.

  • Cloudflare
  • Azure Databricks
  • Microsoft Azure
  • Claude
  • Claude Code
  • Power BI
  • Astro
  • GitLab
  • Microsoft Fabric
  • Resend
  • Unity Catalog
  • Playwright
  • VS Code
  • Python
Shipped

Built and running.

One platform I run at work. One site I built independently. Every number below comes from code, logs or direct measurement.

Architecture simplified and anonymised.

The data platform I run

Day job · Global freight and logistics

I run the data platform for a global logistics company. It loads 650 tables from 16 systems and feeds the company's reports. I took over the contractor-built platform in 2023 and now run it end to end.

  • It loads about 700 GB automatically every weekday.
  • I migrated more than 50 stored procedures and functions from T-SQL to Databricks, and proved the new numbers matched the old ones before the switch.
  • I rebuilt a 34-page report as 11 smaller reports, cutting refresh time from 92.9 to 4.1 minutes.
  • I am the technical lead across an 11-person BI team spread over South Africa, the USA and India.

Azure Databricks · Unity Catalog · Fabric · Power BI · GitLab CI

How the platform loads 650 tables

Inside the platform · Loading

More than 900 configuration rows, one per configured load, tell shared loaders what to load, where it goes and how much can run at once. Most new loads need a row, not a new pipeline.

  • The first loader copies source data. The second links it and records where it came from. The third builds tables for reports.
  • Source loads run 10 at a time. Later steps can run up to 100 at a time.
  • For the busiest source, the platform reads only what changed since the previous run.
  • An automated check catches code that reads from the wrong layer.

Databricks Workflows · for-each tasks · Delta Lake · JDBC · Python

From test to production

Inside the platform · Release path

Every change to production is reviewed, tested and deployed through GitLab. Nobody pushes straight to production. Developers work on a separate test environment.

  • Every production table is cloned to test each day, inside the same governed catalog, so test never has to load from the source systems.
  • Test can read production data, but it cannot change it.
  • Production and test have separate networks and storage. Passwords and keys stay in a vault, never in code.
  • People get access through company groups. Scheduled jobs use machine accounts.

Azure Databricks · GitLab CI · Unity Catalog · Entra ID · Key Vault

Independent project · konradvanstaden.com

I replaced an ageing Joomla site with a static site and added online booking.

  • It has a homepage and one page for each of the author's 18 books.
  • Fonts, scripts and images come from its own domain. Social embeds load only when clicked.
  • The old email booking option stayed available until online booking was ready.
  • The scripted launch could be rolled back within five minutes. I checked the live site before calling it done.
Visit the live site ↗

Astro · Cloudflare Pages · Pages Functions · Resend

    If you run a platform like this, or need one built and kept honest, tell me what you are trying to change.

    How I work

    One half runs in shadow. The other returns to the light before it ships.

    The way I work is the product.

    1. PlanFrameSet the goal and limits.
    2. PlanReplayThe AI says the plan back plainly.
    3. ImplementRunWork in shadow.
    4. ReviewVerifyReturn with proof.
    5. ReviewShipRelease the verified result.

    What repeats becomes a safeguard.

    The machine's half

    What can run without me.

    The longest unattended run so far was 1 019 steps. Every run is logged and its result checked.

    Watch first, then trust

    I watch new automations until they are reliable. Spending money, publishing and deleting always need my approval.

    Bull in a china shop, then a diamond

    Build the rough version fast in a separate, safe environment. Then harden, test and document it before release.

    The same setup sorts email, handles support tickets and writes meeting notes. In one supervised run, it diagnosed a fault with my home internet and logged the support request.

    My half

    What still needs my judgment.

    If I cannot explain a change plainly, I do not ship it.

    Explain the plan first

    Before work starts, the AI explains the plan in plain English. I correct any misunderstanding first.

    Verify the real result

    A success message is not proof. I check what people will actually see or receive.

    Turn mistakes into safeguards

    When a mistake repeats, I turn it into a rule or an automated check. Serious risks get a safeguard immediately.

    Contact

    Start a conversation

    Tell me what you are trying to change, what is blocking it, and the outcome you need.

    Email Kosie

    contact@kosieroux.com

    Kosie Roux · Technical Lead Data Engineer · Gqeberha, South Africa · LinkedIn

    Source to report: the lakehouse I runSources (ERP, warehouse systems, files and APIs) load a Databricks lakehouse of silver, warehouse and gold layers driven by settings tables; serverless SQL warehouses serve Power BI, a Fabric mirror and natural-language query; Unity Catalog governs the whole platform. Secrets live in Key Vault with storage on ADLS Gen2, and GitLab CI deploys every change from test to production.JDBCJDBCHTTPSREADJDBCODBCRESTGOVERNSECRETSDEPLOYDATABRICKS LAKEHOUSEERP systemsSQL Server · two instancesWarehouse systemsPostgreSQL · 3 versionsFiles & APIsSharePoint · SFTP · RESTETLWorkflows & pipelinesdriven by settings tables · one loader per layer · loads only what changedS_Silversource copies · as isW_Warehouselinked and traceableSTG_Stagingoptional · one-off shapesG_Goldready for reportingSERVEServerless SQL warehousesservice account login · JDBC / ODBC endpoint · stops when idlePower BIdatasets · paginatedFabric mirrorDataflow Gen1AI/BI Genienatural languageUnity Catalogone metastore, two workspaces · production controlled · test isolated · access rules, lineage, row filtersAzure Key Vault & ADLS Gen2secrets in a vault · no password in code · Delta storage under managed external locationsGitLab CI/CDtest → merge request → main → production · layer-order and join checks run on every mergeTYPE KEYSource / consumerFocal surfaceOptional layerPrimary data pathPlatform-wide serviceOrchestrated Source to report: the lakehouse I runSources (ERP, warehouse systems, files and APIs) load a Databricks lakehouse of silver, warehouse and gold layers driven by settings tables; serverless SQL warehouses serve Power BI, a Fabric mirror and natural-language query; Unity Catalog governs the whole platform.GOVERNREADDATABRICKS LAKEHOUSESource systemsERP · warehouse systems · files and APIs · 16 in allETLWorkflows & pipelinesdriven by settings tables · one loader per layerS_Silversource copies · as isW_Warehouselinked and traceableG_Goldready for reportingSERVEServerless SQL warehousesJDBC · ODBC · REST · stops when idleReportsPower BI · Fabric mirror · AI/BI GenieUnity Catalogone metastore · production controlled · test isolated · lineage
    Settings drive each loadMore than 900 settings rows drive the loads: a daily job reads them and groups the work, and three shared loaders copy source data to silver, link and trace it into the warehouse, and build report tables in gold; an automated check flags code that reads from the wrong layer.CHECKSSETTINGS900+ settings rowsone row per configured load · what, where, how many at onceJOBDaily jobreads the settings · groups the workCOPYCopy source datasource → silver10 source loads at a timeLINKLink and tracesilver → warehouseup to 100 at a timeBUILDBuild report tableswarehouse → goldup to 100 at a timeLayer checkan automated check flags code that reads from the wrong layer · each layer reads only the layers before itSettings drive each loadMore than 900 settings rows drive the loads: a daily job reads them and groups the work, and three shared loaders copy source data to silver, link and trace it into the warehouse, and build report tables in gold; an automated check flags code that reads from the wrong layer.CHECKSSETTINGS900+ settings rowswhat to load · where it goes · how many at onceJOBDaily jobreads the settings · groups the workCOPYCopy source datasource → silver10 source loads at a timeLINKLink and tracesilver → warehouseup to 100 at a timeBUILDBuild report tableswarehouse → goldup to 100 at a timeLayer checkflags code that reads from the wrong layer
    How code reaches Databricks: the release pathA developer's feature branch becomes a GitLab merge request, is checked by a pipeline and held by a merge gate that lets no one push to main; merging deploys main to both the production and test Databricks workspaces through machine logins, and main is merged back into every open branch.DEVELOPERlocal checkoutGITLABthe platform repoDATABRICKStwo workspacesPUSHPROD SPTEST SPMERGED BACKBRANCHFeature branchone per change · relative %runchecks run locally firstMRMerge requestbuild · validate · testcode scan · secret scanPOLICYMerge gateno one pushes to maincritical or high findings blockDEPLOYmaindeploy stage · 3 jobsmachine login · no personal tokensPRODProduction workspacemain onlyproduction catalogTESTTest workspacemain + the branch under testcloned from production dailya repo folder is a branch checkout, so relative paths are what keep test off production codeTYPE KEYGate & deployStepFlowDeploy triggerAuto-merge backHow code reaches Databricks: the release pathA developer's feature branch becomes a GitLab merge request, is checked by a pipeline and held by a merge gate that lets no one push to main; merging deploys main to both the production and test Databricks workspaces through machine logins, and main is merged back into every open branch.DEVELOPERGITLABDATABRICKSPUSHMERGED BACKBRANCHFeature branchone per change · checks run locally firstMRMerge requestbuild · validate · testcode scan · secret scanPOLICYMerge gateno one pushes to maincritical or high findings blockDEPLOYmaindeploy stage · 3 jobsmachine login · no personal tokensPRODProductionmain onlyproduction catalogTESTTestmain + branch under testprod cloned dailya repo folder is a branch checkout,so relative paths keep test off production code