Microsoft SQL Server development
The database a great many established business systems in this region already run on — and where most of their performance problems live.
Relational database
Chosen per project
Maintainable handover
Where a business has been running packaged or bespoke software for a decade, the odds are good that SQL Server is underneath it. That makes it less a technology choice than a fact to work with — and usually the cheapest place to improve a slow system.
The pattern we see repeatedly is a schema that grew by addition, indexes created for problems long gone, and a handful of queries responsible for most of the load. Finding those is a day of work; rewriting the application is months.
What we build with SQL Server
Existing .NET and ERP systems built on SQL Server
Reporting that has begun to interfere with daily operations
Integrating a legacy database with a new application or API
Migration to Azure SQL or a managed instance
Where it fits — and where it does not
Good fit when
Transactional business systems already on the platform
Organisations standardised on Microsoft tooling
Complex reporting needing window functions and stored procedures
Consider something else when
Greenfield projects with no Microsoft dependency — PostgreSQL avoids the licence
Document-shaped data with no fixed schema
How a slow system gets diagnosed
In that order. Reversing it is how people end up buying hardware that does not help.
Find the top queries
Query Store ranks by total load, not by complaint.
Read the plan
Scans, spills and bad estimates show up here.
Fix indexes or SQL
Usually one index or one rewrite carries most of the gain.
Re-measure
Confirm on real load before touching anything else.
How we work with SQL Server
Measure before changing
Query Store and execution plans identify the small number of statements causing most of the load, before anything is rewritten.
Indexes with intent
Missing indexes added, unused and duplicate ones removed — the second half is skipped surprisingly often, and it costs on every write.
Set-based rewrites
Row-by-row cursors replaced with set operations where that is what is actually slow.
Backups proved
Full and log backups on a schedule, with a restore actually performed rather than assumed.
Our typical SQL Server setup
| Concern | What we use |
|---|---|
| Versions | SQL Server 2016 onwards, Azure SQL, Managed Instance |
| Diagnosis | Query Store, execution plans, wait statistics |
| Schema | Normalised transactional design, with reporting views where useful |
| Programmability | Stored procedures and functions, kept in source control |
| Operations | Backup, restore testing and index maintenance jobs |
Frequently asked questions
Usually. It is typically reporting queries scanning large tables while transactions are running. Options range from an index and a rewrite to moving reporting onto a replica — we would measure first and recommend the cheapest effective one.
Only if the migration cost is genuinely repaid. For an existing application with stored procedures and .NET data access, that is a substantial rewrite, and moving to a managed SQL Server tier is often the better economics.
Yes, and that is most of this work. It begins with reading the schema and the top queries rather than proposing changes.
Topics people search for
Services built with SQL Server
Enterprise Software Development
Systems for organisations where several departments, sites and approval chains all have to work from the same data.
Custom Software Development
Software shaped around the way your business already works, instead of a packaged product you have to reorganise around.
Software Maintenance
Keeping working systems working — including ones built by somebody else.
Digital Transformation
Moving a business off paper and spreadsheets without stopping the business to do it.
Tell us what you are trying to build
Describe the problem in plain language and we will tell you what it would take to solve it — the approach, the moving parts and the sensible order to build them in. No obligation either way.