Azure data engineering and Synapse

Synapse is not going away tomorrow, and a working dedicated pool with tuned distributions is a real asset. The honest decision framework is: new greenfield analytics usually starts in Fabric; existing Synapse estates with heavy T-SQL dependencies and stable costs are often better left in place and surfaced through Fabric or Power BI. We model both paths against your workloads and costs before recommending either.

Yes. It is a large part of what we do. We begin with a documented assessment, because taking responsibility for undocumented infrastructure without one is how people end up owning somebody else's outage. You get the assessment whether or not you continue with us.

Tagging so every resource maps to a workload and owner, compute that pauses or scales down when idle, storage lifecycle rules, and a monthly review against a baseline. Most of the savings we find are not clever. They are a dedicated pool left running at the weekend, logs retained for seven years by default, or a pipeline doing a full reload because incremental was never finished.

Yes. We are Microsoft-focused but not Microsoft-only, and plenty of estates run Databricks for engineering with Power BI for serving. We will not propose replacing a well-run Databricks platform to make an architecture diagram tidier.

Assertions that run with every load: row counts within expected tolerance, referential integrity on keys, uniqueness on business keys, null checks on required fields, and reconciliation totals against the source of record. Failures either block promotion to the serving layer or raise an alert, depending on severity, which is agreed with the business, not chosen by the engineer.