Skip to content

Data

SQL Server

Microsoft’s enterprise database, designed and run by engineers who tune T-SQL and read execution plans in production — and who will tell you when you don’t need the licence.

Overview

Microsoft SQL Server is a mature, enterprise-grade relational database that has been the backbone of the Windows and .NET world for decades. It is fully ACID-compliant, ferociously well-supported, and paired with tooling — SQL Server Management Studio, the Azure Data Studio family, and a query optimiser that has been refined over twenty-five years — that few databases can match for polish. When a team is already living inside the Microsoft ecosystem, SQL Server is not just a reasonable default; it is usually the right one, because the friction of connecting it to C#, ASP.NET, and Azure is close to zero.

Its dialect is T-SQL, Microsoft’s procedural extension to SQL, and its reach goes well beyond storing rows. SQL Server ships a genuine data platform: Integration Services (SSIS) for ETL, Reporting Services (SSRS) for pixel-perfect operational reports, and Analysis Services (SSAS) for OLAP cubes and tabular models. On the engine side it has features that earn their keep under load — columnstore indexes for analytical queries against transactional data, In-Memory OLTP for latency-critical write paths, and Always On availability groups for high availability and readable secondaries. In the cloud the same engine appears as Azure SQL Database, a fully managed service that removes most of the operational burden while keeping the T-SQL surface your application already speaks.

We use SQL Server where it belongs: inside Microsoft-centric estates, behind .NET applications, and in enterprises that already run it and need it designed, tuned, and operated properly. We are equally blunt about the other side of the ledger. SQL Server is commercial software with per-core licensing that gets expensive quickly, and for a greenfield project on a non-Microsoft stack, PostgreSQL delivers comparable capability with no licence cost at all. We will say so plainly rather than talk you into a bill you did not need to pay.

Best for — Enterprises and products built on .NET and Azure, and existing SQL Server estates, that need a supported, feature-rich relational platform designed, tuned, and operated by engineers who read execution plans — not teams paying for a licence they could have avoided.

Why teams choose SQL Server

  • Native fit with .NET and Azure

    Inside the Microsoft ecosystem, SQL Server removes friction rather than adding it. Entity Framework, ADO.NET, Azure Active Directory authentication, and the managed Azure SQL Database service all assume it, so the connective tissue between your application, your identity provider, and your database is well-trodden instead of bespoke. Teams ship faster because the integration work is already done.

  • A data platform, not just a database

    SSIS for ETL, SSRS for operational reporting, and SSAS for OLAP and tabular analytics come with the platform and are built to work together. For an enterprise that needs transactional storage, scheduled data movement, and business reporting under one supported roof, that consolidation is worth real money — you are buying an integrated stack, not assembling one.

  • Enterprise support behind you

    A commercial licence buys a support relationship, a predictable patching and lifecycle policy, and the certifications that regulated environments demand. For organisations where an unsupported database is a governance problem in its own right, that backing is part of what they are paying for — and it is a legitimate part of the value.

Why businesses choose SQL Server

  • Your stack is already Microsoft — C#, ASP.NET, Azure — and you want a database that fits it without a layer of adapters and surprises between the application and the data.
  • You have an existing SQL Server estate you need designed, tuned, or rescued properly, rather than migrated away from at a cost that outweighs the licence you were trying to escape.
  • You need its enterprise features — columnstore, In-Memory OLTP, Always On, TDE — and the SSIS/SSRS/SSAS platform, together and supported, and you value that more than you mind the licensing.
  • You want an honest partner who will tune SQL Server hard where it is the right choice and tell you plainly when PostgreSQL would serve a new project better for nothing — rather than one whose advice quietly tracks the licence they can sell.

What we build with SQL Server

The capabilities this technology is genuinely strong at — and what we most often build with it.

  • T-SQL, stored procedures, and the query optimiser

    T-SQL is a rich, mature procedural SQL dialect, and SQL Server’s cost-based optimiser is one of the best in the business at turning a declarative query into an efficient plan. We write set-based T-SQL rather than row-by-row cursors, use stored procedures and parameterisation deliberately, and lean on the optimiser’s statistics and plan cache instead of fighting them — because working with SQL Server’s optimiser rather than against it is most of what performance tuning on this engine actually is.

  • Columnstore indexes for analytics on live data

    Clustered and non-clustered columnstore indexes store data column-wise with heavy compression and batch-mode execution, so analytical queries scan orders of magnitude faster than a row store would. We use them to run reporting and aggregation against operational tables without standing up a separate warehouse for every dashboard — real-time analytics on transactional data, in the same database, when the scale suits it.

  • In-Memory OLTP for hot write paths

    Memory-optimised tables and natively compiled stored procedures move latency-critical, high-contention workloads into a lock-and-latch-free structure that removes the concurrency bottlenecks a traditional disk-based table hits under heavy concurrent writes. We reach for it surgically — session state, ingestion buffers, hot counters — where the profiling shows contention is the real ceiling, not as a blanket setting.

  • Always On availability groups

    Always On availability groups provide high availability and disaster recovery with automatic failover and one or more readable secondary replicas. We use the secondaries to offload reporting and read-heavy traffic from the primary, and design the failover and quorum configuration so a node loss is a non-event rather than an outage — the difference between a resilient system and one that merely has a backup.

  • Transparent Data Encryption and row-level security

    TDE encrypts data at rest — data and log files, and backups — with no application change, closing off the stolen-disk and stolen-backup threat. Row-level security enforces which rows a given user or tenant may see inside the database itself, where a bug in the application layer cannot bypass it. Together with Always Encrypted for the most sensitive columns, they let us push security into the engine rather than trusting the app to get it right every time.

  • The SSIS, SSRS, and SSAS platform

    Integration Services handles scheduled ETL and data movement, Reporting Services produces the pixel-perfect operational reports enterprises still run their businesses on, and Analysis Services builds OLAP cubes and tabular models for slice-and-dice analytics. We build with these where they fit — and are candid when a lighter, cloud-native pipeline would serve a new requirement better than the classic stack.

Use cases

  • .NET line-of-business applications

    The transactional store of record behind C# and ASP.NET business systems — orders, accounts, inventory, workflow — where Entity Framework and the Microsoft tooling make SQL Server the natural fit and the constraint system enforces the business rules the application must never violate.

  • Azure-hosted products on managed SQL

    Cloud applications running against Azure SQL Database, where the managed service absorbs patching, backups, and high availability, and the team keeps a familiar T-SQL surface — with schema, indexing, and cost tuned so the managed convenience does not turn into a surprising monthly bill.

  • Operational reporting and BI

    Enterprises that need scheduled ETL, governed reporting, and OLAP analytics together — SSIS pipelines feeding a model, SSRS or Power BI reporting over it, and columnstore for real-time aggregation against operational data without a separate warehouse for every question.

  • High-availability enterprise estates

    Mission-critical systems where downtime has a direct cost — Always On availability groups for automatic failover and readable secondaries, TDE and row-level security for compliance, and a support relationship the organisation’s governance requires — designed and operated to stay up under real conditions.

When SQL Server is the right choice

  • You are already on .NET and Azure. If your application is C# and ASP.NET, and your infrastructure is Azure, SQL Server (or its managed form, Azure SQL Database) is the path of least resistance and least surprise — Entity Framework, the tooling, the identity integration, and the support all line up, and the productivity gain is real.
  • You have an existing SQL Server estate. Migrating a working, well-understood SQL Server system to something else to save on licensing is rarely the win it looks like on a spreadsheet — the migration risk, the T-SQL and SSIS rewrites, and the retraining usually cost more than the licence. Keeping and tuning what you have is often the honest answer.
  • You need its enterprise and BI features together. Columnstore for real-time analytics on operational data, In-Memory OLTP for hot write paths, Always On for high availability, and the SSIS/SSRS/SSAS stack for ETL and reporting — having those in one supported, integrated platform, with an enterprise support contract behind them, is a genuine reason to choose it.
  • You need a formal support relationship and compliance posture that a vendor stands behind. Regulated environments and large enterprises often value Microsoft’s support, certifications, and predictable patching more than they mind the licence — and that is a legitimate basis for the decision.
  • Wrong for: a greenfield project on a non-Microsoft stack with no existing SQL Server investment. Here PostgreSQL gives you comparable correctness, richer extensibility, and equivalent capability for the workloads most teams actually have — with no per-core fee. If nothing is pulling you towards Microsoft, paying for SQL Server is spending money to solve a problem you do not have.

SQL Server: pros and cons

Strengths

  • A mature, extremely well-supported engine with a query optimiser and execution-plan tooling that are genuinely best-in-class — diagnosing and fixing a slow query on SQL Server is a well-lit path, not a dark art.
  • Deep, frictionless integration with the whole Microsoft stack: C#, ASP.NET, Entity Framework, Azure, and Active Directory line up so cleanly that the database rarely fights the application.
  • A serious feature set for demanding workloads — columnstore indexes, In-Memory OLTP, Always On availability groups, Transparent Data Encryption, and row-level security — available and supported in one platform.
  • Azure SQL Database offers the same engine as a fully managed service, taking patching, backups, and much of high availability off your plate while keeping the T-SQL your code already speaks.

Trade-offs

  • Commercial per-core licensing is expensive and scales with your hardware in a way that surprises teams — Enterprise edition in particular can dwarf the cost of the servers it runs on, and the features you actually want are often the ones gated behind it.
  • It is at its best inside the Microsoft, Windows, and Azure world. Run it outside that ecosystem — on Linux, behind a non-.NET stack, away from Azure — and it works, but you lose much of the integration advantage that justified choosing it over a free alternative in the first place.
  • For a greenfield non-Microsoft stack, PostgreSQL usually matches it for capability at zero licence cost. Paying for SQL Server only makes sense when something is genuinely pulling you towards Microsoft; absent that, the licence is money spent for no corresponding gain.
  • The BI stack (SSIS, SSRS, SSAS) is powerful but shows its age and its Windows heritage — it can be heavyweight to operate and develop against, and modern cloud-native alternatives sometimes fit new work better than reaching for the classic Microsoft tools by reflex.

Architecture

We treat the schema and the T-SQL layer as the load-bearing design of the system, because both are hard to change once an application and its data have grown around them. That means a properly normalised relational core with real foreign keys, check constraints, and sensible clustered-index choices, and indexes designed against the queries the application actually runs — rowstore B-tree indexes for point and range lookups, columnstore where the workload turns analytical, and filtered and covering indexes where they earn their maintenance cost. Stored procedures and parameterised access are used where they add clarity and plan stability, not as dogma.

Around the engine we design for the deployment that fits. On Azure SQL Database we lean on the managed service for backups and high availability and focus our effort on schema, indexing, and cost control, because the pricing tiers reward — and punish — design decisions directly. On self-managed SQL Server we design the Always On topology, tempdb configuration, and read-replica routing deliberately, and we plan migrations to run safely under production load so a schema change on a large table is never an outage. Where reporting load competes with transactions, we separate the two — readable secondaries, columnstore, or a downstream model — rather than letting analytics starve the transactional primary.

Performance

SQL Server gives you unusually good tools for finding out why a query is slow, and we use them rather than guessing. Execution plans — estimated and actual — show exactly where time and rows go; Query Store captures plan history and regressions over time; and the dynamic management views expose waits, missing-index suggestions, and the queries that dominate load. Most performance problems here are the familiar ones: missing or wrong indexes, stale statistics, parameter-sniffing gone bad, and row-by-row cursors where set-based T-SQL belonged. A single well-placed index or one rewritten query routinely beats any amount of extra hardware.

Configuration and maintenance matter and are workload-specific. Tempdb sizing and file layout, MAXDOP and cost-threshold settings, statistics maintenance, and index fragmentation all need attention appropriate to the data and access pattern rather than left at defaults. On Azure SQL the same discipline also controls cost directly, because an under-indexed workload simply consumes a higher service tier to do the same work. We tune from evidence measured against representative data volumes — not against a near-empty development database that hides every problem until production finds it.

Security

SQL Server has a deep, mature security model and we use it rather than leaning on the application alone. Least-privilege logins and database roles so services can do only what they need; row-level security to enforce tenant and record isolation inside the engine where an application bug cannot bypass it; Transparent Data Encryption for data and backups at rest; and Always Encrypted for the most sensitive columns, so plaintext never reaches the server. Parameterised queries — always — close off SQL injection at the source rather than filtering for it after the fact.

Operational security is the other half. On Azure SQL we use Azure Active Directory authentication and managed identities so credentials are not scattered through configuration, and firewall and private-endpoint rules so the database is never exposed to the open internet. On self-managed instances we keep the engine patched, restrict network access, and hold backups encrypted, access-controlled, and — the part teams skip — actually restore-tested, because a backup you have never restored is a hope, not a recovery plan. Auditing captures who did what where the compliance context calls for it.

Scalability

The honest scaling story for SQL Server mirrors most single-primary relational databases: it scales up superbly and scales reads well, and scaling writes horizontally is genuinely hard. A well-tuned instance on capable hardware, or a high Azure SQL service tier, handles far more transactional load than most teams expect, and Always On readable secondaries fan read-heavy and reporting traffic across nodes. For the large majority of systems this is the entire scaling plan and it works for years. We reach for indexing, partitioning of very large tables, columnstore for analytical load, and replica routing long before anything more exotic.

Beyond a single primary the options carry real cost, and licensing sharpens the trade-off in a way it does not for open-source engines: bigger hardware and higher service tiers mean more cores to pay for. Sharding across instances is application-level engineering with lasting complexity in cross-shard queries and transactions, and there is no free lunch that removes it. We are blunt about this — most teams who think they need to scale out actually need better indexing, their analytics moved off the primary, and a read-replica strategy. And where a new, non-Microsoft workload is heading towards an expensive scale-up purely to avoid a rewrite, we will say honestly whether the licensing maths still favours staying on SQL Server or whether it is time to reconsider.

SQL Server integrations & ecosystem

The technologies we most often pair with it — each links to how we work with it.

How we work

We start with the data model and the deployment decision, because both are load-bearing. That means understanding the domain, defining the constraints that must always hold, planning indexes and access patterns before features are built on top, and deciding early between self-managed SQL Server and Azure SQL Database — the two reward different design choices, and choosing the wrong target and adapting later is expensive. Migrations are version-controlled and written to run safely under production load from day one, not improvised in a maintenance window.

The engineers who design your schema are the ones who tune the T-SQL, read the execution plans, and keep it running — which is what we mean by operating what we build. That shapes the choices we make: index designs that hold up at real volume, tempdb and statistics maintained, security pushed into the engine, and restore-tested backups, because we are the people who would be on the other end of the incident if those were done carelessly. And because SQL Server costs money to run, we treat licensing and service-tier cost as a design constraint, not an afterthought.

The service behind it

Delivered throughData Engineering

What we build with SQL Server

The disciplines this technology most often shows up in — from a first build to taking over and stabilising an existing one.

How we deliver

  1. 01

    Discover

    We map the system, the constraints and the business it serves — including the parts nobody documented.

    Architecture brief

  2. 02

    Architect

    Decisions get made, written down and defended before a line of production code exists.

    Decision records

  3. 03

    Build

    Short cycles against working software. You see progress in the product, not in a status deck.

    Shipping increments

  4. 04

    Operate

    Monitoring, incident response and iteration. The system is alive, so the engagement is too.

    Runbooks & SLOs

Industries we use SQL Server in

Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.

Also in Data

Why teams choose us for SQL Server

  • Senior engineers only

    Database design and T-SQL are where a project’s worst, most expensive mistakes get made — and they surface years later, under load, when they are hardest to fix. The people modelling your schema, writing your stored procedures, and reading your execution plans have done it many times before. There are no juniors learning indexing and plan-tuning on your production data.

  • We operate what we build

    We run the SQL Server and Azure SQL databases we design, so we optimise for the on-call reality rather than the demo: indexes that hold up at real volume, tempdb and statistics maintained, Always On proven by actual failover tests, and backups that have really been restored. You get a database that stays fast and correct under real traffic, not just in a benchmark.

  • Deep in the Microsoft stack

    We work across C#, ASP.NET, Azure, and SQL Server together, so we design the database with full knowledge of the application and infrastructure around it — Entity Framework behaviour, Azure identity, service-tier economics — instead of treating the database as a box someone else’s code happens to talk to.

  • Honest about the licence

    We will tune SQL Server hard where it is the right choice, and tell you plainly when a greenfield non-Microsoft project would be better served by PostgreSQL for no licence cost at all. Our advice tracks what your project actually needs — not the software we could bill you for running.

Typical timeline

  1. 01

    Discovery and data modelling

    One to two weeks understanding the domain and workload, designing the schema and constraints, and settling the deployment target — self-managed SQL Server or Azure SQL Database — so the foundations, and their cost implications, are decided before code grows on top of them.

  2. 02

    Build and instrumentation

    Implementing the schema with version-controlled migrations, wiring in the data access layer (typically Entity Framework or Dapper), and putting Query Store, monitoring, and slow-query visibility in place from the start rather than after the first incident.

  3. 03

    Tuning and load validation

    Indexing and configuration tuned against representative data volumes, queries profiled through execution plans and the dynamic management views, tempdb and statistics maintenance set up, and — on Azure SQL — the service tier validated against real load and cost rather than guessed.

  4. 04

    Hardening and handover

    Security review, restore-tested backups, an Always On or managed high-availability configuration proven by failover testing, a documented scaling plan, and documentation so your team can own and extend the database.

How pricing works

  • Fixed-scope engagements for well-defined work — a schema design and build, a T-SQL and index performance audit, or a migration onto SQL Server, between versions, or across to Azure SQL Database — quoted once we understand the data, the workload, and the constraints.
  • Monthly senior engagement for ongoing product work where the database evolves with a .NET application and you want continuity of the people who know your schema and your T-SQL, rather than a fixed deliverable.
  • Focused audits and rescues for struggling SQL Server deployments — slow queries, blocking and deadlocks, plan regressions, or a runaway Azure SQL bill — priced by the assessment, and including an honest view on whether the licensing still makes sense for your case.

Hire SQL Server engineers

Need SQL Server capacity on your own team? We embed named senior engineers into your existing team — reporting to your leads, working in your rituals — so you add capacity without a hiring cycle.

Hire SQL Server engineers

Common questions

SQL Server or PostgreSQL — which should we use?

It depends almost entirely on your existing stack. If you are on .NET and Azure, or you already run SQL Server, SQL Server is usually the right choice — the integration with C#, ASP.NET, Entity Framework, and Azure identity is frictionless, and the enterprise features and support are real value. But for a greenfield project on a non-Microsoft stack, PostgreSQL matches SQL Server for capability on the workloads most teams actually have, with richer extensibility and no per-core licence to pay. Our default question is simple: is anything genuinely pulling you towards Microsoft? If yes, SQL Server. If not, paying for it is spending money to solve a problem you do not have.

What is the difference between SQL Server and Azure SQL Database?

They are the same core engine with different operating models. SQL Server is the product you install and manage yourself — on Windows or Linux, on-premises or on a virtual machine — where you own patching, backups, and high availability, and you get the full feature surface including SSIS, SSRS, and SSAS. Azure SQL Database is a fully managed platform service: Microsoft handles patching, backups, and much of high availability, and you interact with a familiar T-SQL surface while paying by service tier rather than by core licence. Managed removes a great deal of operational burden, but it moves cost control into schema and indexing design, because an inefficient workload simply consumes a higher, pricier tier. We help you pick the right one for your situation and design for it specifically.

Is SQL Server licensing really that expensive?

It can be, and it is worth understanding before you commit. SQL Server is licensed per core, so the cost scales with the hardware you run it on, and the Enterprise edition — which holds many of the features teams actually want, such as unrestricted columnstore, In-Memory OLTP, and advanced Always On — is considerably more than Standard. For a large enterprise database the licence can exceed the cost of the servers. That is exactly why we are candid about it: where you are already invested in Microsoft, the productivity and support usually justify it, but for a new project with no such pull, PostgreSQL delivers comparable capability for nothing, and we would rather tell you that than watch you pay for a licence you did not need.

Should we migrate our existing SQL Server system off it to save on licensing?

Usually not, and we will tell you honestly when the maths does not support it. Migrating a working, well-understood SQL Server system to another database means rewriting T-SQL and stored procedures, rebuilding SSIS pipelines and reports, retraining the team, and carrying the risk of moving live data — and those costs, plus the disruption, frequently exceed the licensing you were trying to escape. The case for migrating is stronger for greenfield work or for a system already straining against SQL Server’s costs with no offsetting Microsoft dependency. For an established estate, tuning and rightsizing what you have is often the more honest recommendation, and it is one we are happy to make even though it is the smaller engagement.

Can SQL Server handle both our transactions and our reporting?

Often, yes — and consolidating the two is one of SQL Server’s genuine strengths. Columnstore indexes let analytical queries run against operational tables far faster than a rowstore would, and Always On readable secondaries let you push reporting and read-heavy traffic onto separate replicas so it never competes with transactional writes on the primary. For a great many enterprises this removes the need for a separate warehouse for every dashboard. The limit is scale and query complexity: petabyte-scale analytics over the whole history of the business still belong in a dedicated columnar warehouse fed from SQL Server, not run against the transactional primary. We design the split deliberately rather than letting reporting quietly starve your transactions.

Building on SQL Server?

A technical conversation with the engineers who would do the work. If we are not the right fit, we will say so on the call.

Prefer to book a call?Or email [email protected]

Two fields required. We reply to real enquiries — no list, no sequence.