SQLMesh VS Code Extension: Architecture, Stack & Delivery

Introduction

In this article I break down how I designed and delivered SQLMesh VS Code Extension — from the original business pain point through architecture, technology choices, implementation phases, and lessons learned. This is the same project featured in my portfolio's Built Solutions section, documented here in full technical depth for engineers, architects, and hiring managers who want to understand how the work was actually done.

I led this initiative as part of my broader program delivery work across enterprise AI, data platforms, and analytics transformation. The approach reflects how I operate: start with the business outcome, choose the minimum viable architecture, instrument everything, and iterate with real users.

Business problem

Developers context-switched between IDE and pipeline tools to run SQLMesh commands.

Built a VS Code extension to execute and visualize fetchdf commands in-editor.

Architecture decisions

Key design choices that shaped reliability, performance, and maintainability of the solution.

• Executes CLI in workspace context for correct SQLMesh project root
• Limits row preview for performance on large results
• Secrets never stored in extension settings

Technology stack in depth

This project was built with SQLMesh, TypeScript, VS Code API. Each technology was selected for a specific role in the architecture — not because it was trendy, but because it solved a measured bottleneck.

• SQLMesh: production component with documented integration patterns and operational runbooks
• TypeScript: production component with documented integration patterns and operational runbooks
• VS Code API: production component with documented integration patterns and operational runbooks

Implementation timeline

Delivery followed phased milestones with explicit deliverables at each gate. This kept stakeholders aligned and made progress auditable for program reviews.

• Extension scaffold (1 week): VS Code API integration and SQLMesh CLI wrapper.
• → Extension boilerplate
• → Command palette hooks
• fetchdf execution (2 weeks): Run models and render dataframe preview in webview panel.
• → Command runner
• → Output panel
• → Error surfacing
• Team rollout (1 week): Internal docs and pairing sessions with data engineers.
• → README
• → Demo video
• → Adoption tracking

Extension architecture

The extension wraps the SQLMesh CLI in the VS Code workspace context so commands always run against the correct project root. A webview panel renders dataframe previews with row limits for performance on large result sets.

Secrets are never stored in extension settings — connection strings remain in environment variables or SQLMesh config files managed by the platform team.

• Command palette: SQLMesh Run Model, SQLMesh Fetch DF, SQLMesh Plan
• CLI stdout/stderr surfaced in integrated terminal with error highlighting
• Preview capped at 1,000 rows with export-to-CSV option
• Workspace-aware project root detection via sqlmesh.yaml

Adoption and impact

Developer experience investments compound. After internal rollout with pairing sessions and a demo video, iteration cycles on pipeline models dropped because engineers no longer context-switched to terminal-only workflows.

Business outcomes

Reduced developer friction and accelerated pipeline iteration.

Success was measured against adoption, latency/throughput targets, and stakeholder feedback — not just deployment dates. Program reviews tracked these KPIs alongside technical milestones.

Lessons learned

Developer experience investments compound across data platform adoption.

If I were starting again, I would invest even earlier in observability and golden test sets. The cost of retrofitting guardrails after pilot launch always exceeds building them in from day one.