SQL Server development for custom applications

SQL Server is Microsoft's relational database engine. You can install and run it yourself, or use the managed Azure SQL products built on the same engine. We design schemas, write T-SQL and stored procedures, tune queries and plan upgrades for applications that run on it, most often .NET applications.

Talk through your SQL Server project Request an estimate

Schema design, T-SQL and stored procedures
Query and index tuning with Query Store and execution plans
Self-hosted SQL Server or Azure SQL
Staged upgrades with a performance baseline

When SQL Server is the right choice

SQL Server suits applications that sit in the Microsoft ecosystem:

Your application is built on .NET and needs a relational database with strong tooling. Microsoft lists SQL Server Management Studio and Visual Studio integration. See our .NET and C# development page.
You are building a new cloud application. Azure SQL Database is the managed option for that.
You are moving an existing SQL Server application with few changes. Azure SQL Managed Instance is aimed at that.
You run many customers on one system. Elastic pools and row-level security help with tenant separation.

When SQL Server is not the right choice

SQL Server is not the answer to every database need:

You self-host and the edition matters. Standard edition has compute and memory limits, and full availability groups need Enterprise.
You want Azure SQL Database but depend on a feature it lacks. For example, CLR is not supported in SQL Database but is in Managed Instance. Managed Instance or SQL Server on an Azure virtual machine may fit better.
You need control of the operating system. SQL Server on an Azure virtual machine gives it, with the management work that implies.
Your team and tools are built around PostgreSQL or MySQL. Judge on licensing, skills and tooling; there is little reason to switch for its own sake.

What we do with SQL Server

Typical work, described in general terms.

Schema design

Tables, keys and constraints that fit how the application works, with changes managed as versioned scripts.

T-SQL and stored procedures

Queries and stored procedures the application calls, written to be readable, parameterised and testable.

Query and index tuning

Finding slow queries with Query Store and execution plans, and changing indexes and queries with evidence.

Upgrades and migrations

Staged engine and compatibility-level upgrades, and moves from self-hosted SQL Server to Azure SQL.

Security features

Row-level security, encryption at rest and Always Encrypted where the data calls for them.

Availability and backups

Availability groups where the edition allows them, and backups that are tested, because high availability is not a backup.

What SQL Server gives you

Microsoft describes Azure SQL as a family of managed products that use the SQL Server engine: Azure SQL Database for single databases and elastic pools, Azure SQL Managed Instance with close feature parity for migrations, and SQL Server on Azure virtual machines when you need full control. With the managed products, Azure handles patching and backups.

Inside the engine, Query Store tracks queries and plans over time, shows plan regressions and lets you force a previous plan. Execution plans, with missing-index hints, show where time goes. Row versioning under READ_COMMITTED_SNAPSHOT lets readers avoid taking shared locks; it is on by default in Azure SQL Database and off in SQL Server and Managed Instance. Always On availability groups provide high availability with one primary and up to eight secondaries, and Microsoft notes that secondaries are not backups. Row-level security, transparent data encryption and Always Encrypted cover access and encryption needs.

Problems we look for

Most slow SQL Server applications share a short list of causes:

Parameter sniffing: one cached plan that suits some parameter values and not others. SQL Server 2022 and later can help with parameter-sensitive plan optimisation, and Query Store lets us force a known good plan.
Missing and unused indexes: we use the optimiser's hints as a start and confirm with Query Store, because every extra index slows writes.
Deadlocks: often a read-then-update pattern under a stricter isolation level. Row versioning, update locks, batched deletes and efficient indexed queries reduce them.
ORM query patterns: lazy loading can send one query per parent row. Entity Framework's guidance is eager loading or projection.
Compatibility-level upgrades: upgrade the engine first, keep the old level, capture a Query Store baseline, then raise the level and fix regressions by plan forcing.
Connections: one canonical connection string, connections disposed promptly, and a pool sized for the process.

How we work

Measure first: Query Store and execution plans show which queries cost the most, so we do not guess
Change one thing at a time: an index, a rewrite or a setting, then compare against the baseline
Test upgrades on a copy: with a captured baseline, so a regression is found before production
Hand over properly: scripts in your repository, a note of every change and why, and a short guide to reading Query Store

Frequently asked questions

Is Azure SQL the same as SQL Server?

Azure SQL is a family of managed products built on the SQL Server engine. Azure SQL Database and Managed Instance are managed by Azure; SQL Server on a virtual machine is the full product that you manage. Some features differ, so compatibility is checked per product.

Can we upgrade without slowing queries?

Microsoft's guidance is to upgrade the engine without changing the database compatibility level, capture a Query Store baseline, then raise the level and force previous plans where a query regresses.

Does high availability replace backups?

No. Microsoft's availability group documentation states that secondary databases are not backups, and regular backups should continue.

Does an ORM change how the database is tuned?

Indexing works the same way, but an ORM can cause one-query-per-row patterns through lazy loading, and the SQL it generates may need parameterisation. We check both.