Enter your search text in the box above

Select a result to preview

Driving Cost-Efficient Data Architectures for SQL Server, Azure SQL and Fabric using FinOps

#fabcon2026 #session #learning #microsoft #fabcon2026-session

Description

Learn how to optimise SQL Server, Azure SQL and Fabric costs using FinOps practices and AI-driven insights. We’ll explore key cost drivers, show how AI detects inefficiencies, forecasts spend, recommends right-sizing, and helps design smarter, cost-efficient data architectures across hybrid and cloud environments.

Key Takeaways

My Notes

Action Items

Slides

📥 Download Slides

Driving Cost-Efficient
Data Architectures for
SQL Server, Azure SQL
and Fabric using FinOps
Hamish Watson
Hamish
Watson
He/him/WE
DevOps Consultant
Morph iT Limited
CEO & AI Consultant
Make Stuff Go Limited
@theHybridDBA
• Many years mucking about with 1s & 0s
• Bringing DevOps to databases (and the
masses) is a personal passion
• Understanding AI, data and cloud is a
company driver
• Technologist who understands business
value…
• #makeStuffGo
https://www.makestuffgo.com
hamish@makestuffgo.com
The myth of DevOps
Why integrate FinOps with DevOps?
• Scalability and Dynamic Pricing
• Diverse Service Offerings
• Complex Architecture and Management
FinOps is the best mate of DevOps
• Enhanced Cost Efficiency
• Improved Financial Visibility
• Faster Innovation with Accountability
The true effect of FinOps and DevOps
• Automated Cost Monitoring
• Proactive Resource Optimisation
• Continuous Deployment with Cost Control
Tooling to help you with cost management
Driving Cost-Efficient Data Architectures
for SQL Server, Azure SQL & Microsoft Fabric
Applying FinOps + AI to modern data platforms
Core promise
Audience
Outcome
Show where cost actually comes from, how
FinOps makes it visible, and how AI turns cost data
into architectural action.
Data architects
DBAs
Platform engineers
FinOps teams
Leave with concrete patterns for right-sizing,
workload scheduling, and hybrid cost
governance.
Hamish • Conference Session
Opening story: the “why is our data bill so high?” moment
What
happened
Why nobody noticed
earlier
The real lesson
The analytics platform worked brilliantly. Adoption increased.
More teams used the warehouse, notebooks, ETL and
dashboards. Six months later the monthly bill had doubled.
• Compute was sized for peak
• Dev/test stayed online
• Storage kept accumulating
• Multiple teams shared the same
capacity
Cost is not a finance-only problem. It is an
architecture problem. If the platform
shape is wrong, the bill will reflect it.
Why data platform costs explode
• Compute is provisioned for the worst day, but
billed every day
• Storage rarely shrinks; historical data and
duplication accumulate
• Shared analytics environments hide which team
or workload caused spend
• Performance issues are solved by scaling up first
and analysing later
Symptom
“We have good adoption and bad unit economics.”
Root cause
No continuous feedback loop between usage, architecture
and cost.
FinOps answer
Make cost observable enough that engineers can act on it
every week, not every quarter.
#FABCONSQLCON263
Driving Cost-Efficient Data Architectures
for SQL Server, Azure SQL & Microsoft Fabric
Applying FinOps + AI to modern data platforms
Core promise
Audience
Outcome
Show where cost actually comes from, how
FinOps makes it visible, and how AI turns cost
data into architectural action.
Data architects
DBAs
Platform engineers
FinOps teams
Leave with concrete patterns for right-sizing,
workload scheduling, and hybrid cost
governance.
Hamish • Conference Session
#FABCONSQLCON261
Opening story: the “why is our data bill so high?” moment
What happened
Why nobody noticed
earlier
The real lesson
The analytics platform worked brilliantly. Adoption
increased. More teams used the warehouse, notebooks,
ETL and dashboards. Six months later the monthly bill had
doubled.
• Compute was sized for peak
• Dev/test stayed online
• Storage kept accumulating
• Multiple teams shared the same
capacity
Cost is not a finance-only problem. It is
an architecture problem. If the platform
shape is wrong, the bill will reflect it.
#FABCONSQLCON262
Why data platform costs explode
• Compute is provisioned for the worst day, but
billed every day
•
• Storage rarely shrinks; historical data and
duplication accumulate
•
• Shared analytics environments hide which team
or workload caused spend
•
• Performance issues are solved by scaling up first
and analysing later
Symptom
“We have good adoption and bad unit economics.”
Root cause
No continuous feedback loop between usage, architecture
and cost.
FinOps answer
Make cost observable enough that engineers can act on it
every week, not every quarter.
#FABCONSQLCON263
FinOps for data teams: what it actually means
Visibility
Optimisation
Governance
Know who is spending, on what workload, at
what time, and for what business outcome.
Right-size compute, schedule workloads,
remove waste, and choose the right platform
tier.
Create guardrails so the platform stays
efficient as new teams, products and data
volumes arrive.
#FABCONSQLCON264
Where cost shows up across the stack
SQL Server
Azure SQL
Microsoft Fabric
• VM sizing
• Licensing
• HA/DR replicas
• Storage tiering
• Backup retention
• vCore / DTU choice
• Serverless settings
• Elastic pool usage
• Long-running queries
• Idle non-prod databases
• Capacity size
• Shared workload contention
• Notebook / ETL scheduling
• Lakehouse sprawl
• Workspace governance
#FABCONSQLCON265
SQL Server: classic waste patterns
• Oversized VMs and always-on infrastructure for occasional
peaks
•
• Replica and HA topologies sized for resilience but rarely
reviewed for cost
•
• Licensing inefficiency when CPU allocation drifts upward
over time
•
• Hot storage used for cold data because retention strategy is
unclear
Low-effort win
Review HA/DR estate and environment tiers
before buying more hardware or more SQL
licences.
Architectural win
Move from “big iron everywhere” to workloadspecific sizing and lifecycle tiers.
#FABCONSQLCON266
Azure SQL: flexibility creates new optimisation choices
• Right-size vCores against actual workload patterns instead of
migration assumptions
•
• Use serverless carefully; it saves money only when
pause/resume behaviour matches reality
•
• Separate production, dev and test service levels instead of
cloning premium tiers
•
• Surface long-running queries before they silently become a
compute tax
Good FinOps question
“What proportion of our Azure SQL estate is
sized for migration comfort rather than current
demand?”
#FABCONSQLCON267
Fabric: shared capacity makes governance essential
• One capacity can mask multiple competing workloads with
different business value
•
• Interactive analytics, ETL, notebooks and warehousing fight
for the same performance budget
•
• Without scheduling, overnight and background jobs consume
premium capacity for low-value work
•
• Workspace sprawl makes ownership and optimisation
difficult
Fabric mindset shift
Think in terms of workload management and
capacity economics, not just feature
enablement.
#FABCONSQLCON268
Bad architecture vs good architecture
Bad: platform built for fear
Good: platform built for economics
• One large always-on environment
• Shared by every team
• No scheduling
• No ownership per workload
• Cost reviews happen after the bill arrives
• Workloads isolated by value and criticality
• Non-prod environments scaled differently
• Capacity scheduled around demand
• Owners can see what they consume
• Optimisation is part of weekly operations
#FABCONSQLCON269
Architecture diagram 1: hybrid data platform to FinOps
insight
Apps
SQL Server
Fabric
Lakehouse / WH
Azure SQL
FinOps
Insight
Operational data moves through the platform. Telemetry, utilisation and spend signals move with it.
#FABCONSQLCON2610
Architecture diagram 2: the FinOps control loop
Usage
Cost +
Telemetry
Analysis
Action
Measure → attribute → analyse → change architecture → measure again
#FABCONSQLCON2611
AI optimisation pipeline
Usage
telemetry
Spend
records
AI
analysis
Recommend
ations
Ops
automation
Typical outputs: anomaly detection, spend forecasting, right-sizing suggestions, workload scheduling and
environment shutdown windows.
#FABCONSQLCON2612
Architecture diagram 3: demo architecture
Azure
Cost
Data prep
model
AI
assistant
Dashboard +
Terraform suggestion
Platform
metrics
The demo shows AI reading cost + usage data, highlighting waste, and proposing an operational response.
#FABCONSQLCON2613
Demo walkthrough: what the audience should expect

  1. Ingest
  2. Analyse
  3. Recommend
  4. Act
    Bring together spend data,
    query/load telemetry and
    capacity history.
    Ask AI to find anomalies, idle
    assets, underused capacity
    and suspicious growth
    patterns.
    Generate right-sizing,
    scheduling and ownership
    recommendations for
    engineering teams.
    Turn the most valuable
    suggestions into a backlog
    item, policy or Terraform
    change.
    #FABCONSQLCON2614
    FinOps maturity model
    Crawl
    Visibility
    Walk
    Optimisation
    Run
    Automation
    Allocate spend
    Name owners
    See waste
    Right-size
    Schedule
    Tune workload mix
    Guardrails
    Policy
    AI-assisted operations
    #FABCONSQLCON2615
    Where AI agents can genuinely help
    • Summarise what changed in spend this week and point to
    the most likely causes
    •
    • Suggest which environments can be scaled down, paused or
    rescheduled safely
    •
    • Draft Terraform or policy changes for human review instead
    of starting from scratch
    •
    • Turn raw telemetry into plain-language operational advice
    for platform teams
    Important constraint
    An agent should recommend and accelerate. It
    should not become an unsupervised cost
    optimiser with no architectural context.
    #FABCONSQLCON2616
    A simple operating model for FinOps in data teams
    Weekly
    Monthly
    Quarterly
    Review anomalies, idle assets, capacity
    hotspots and non-prod usage.
    Review architectural patterns, service tier
    choices and ownership alignment.
    Revisit platform shape: where to
    consolidate, isolate, retire or automate.
    #FABCONSQLCON2617
    CASE STUDY
    Covid wasn’t completely bad….
    Discussion Points – each week then monthly
    • What’s usage like?
    • What’s the cost rate been like?
    • What’s happened in the past month?
    • What’s next?
    This week is going to be big…
    Let’s zoom out a bit…
    Today – 19,000 users
    AVMA ~3,000 users
    Siggraph – 10,000 users
    Visa – 8,000 users
    The effect on the database - cores
    Core Count
    How hot were we running?
    We were using 30% CPU across 36 cores
    Burn rate - $ (App Services)
    6th July
    14th July
    25th July
    27th July
    August w/e
    August weekday
    September w/e
    September w/day
    $3,520 / day
    $4,235 / day
    $3,310 / day
    $5,534 / day
    ~$845 /day
    ~$2,500 / day
    ~$407 / day
    ~$904 / day
    ( ON FIRE)
    (4 App Service Plans)
    (first scale down weekend)
    (all apps scaled out to max)
    (automated scale/monitoring)
    (scaled out)
    (more scaling in)
    (true scaling implemented)
    Burn rate - $ (Database Cores)
    More straightforward:
    6th July
    August w/e
    August w/day
    September w/e
    September w/day
    $2,530 / day
    $964 / day
    $1,530 / day
    ~$260 / day
    ~330 / day
    Database scaling – eye on perf vs $
    How did we make the database better…
    DEMO!!
    Let’s see some of this in action
    Key takeaways
    • Cost efficiency is a platform design outcome, not a procurement
    exercise
    •
    • SQL Server, Azure SQL and Fabric each have distinct waste
    patterns; treat them explicitly
    •
    • The winning pattern is a control loop: observe, attribute, analyse,
    act
    •
    • AI becomes valuable when it turns cost data into faster
    architectural decisions
    One action to start
    next week
    Pick one shared analytics
    environment and map its top
    workloads, owners and active hours.
    That alone usually exposes the first
    optimisation win.
    #FABCONSQLCON2618
    Questions?
    Happy to discuss Fabric capacity strategy, Azure SQL right-sizing,
    SQL Server estate review, or AI-assisted FinOps operations.
    #FABCONSQLCON2619
    hamish@morphit.co.nz
    https://www.makestuffgo.com
    LinkedIn: /hamishwatson8
    Sound off.
    The mic is all yours.
    Influence the product roadmap.
    Join the Fabric User Panel
    Join the SQL User Panel
    Share your feedback directly with our
    Fabric product group and researchers.
    Influence our SQL roadmap and ensure
    it meets your real-life needs
    https://aka.ms/JoinFabricUserPanel
    https://aka.ms/JoinSQLUserPanel