Databases and data
Applications get rewritten. Frameworks fall out of fashion. The data, and the schema it lives in, outlast all of it.
We design schemas, tune queries, and run migrations on Azure SQL and SQL Server. When an application gets slow, the cause is usually in the database, and it is usually specific: a missing index, a query that reads a million rows to return ten, a lock held across a network call. We find the specific thing.
The usual story
More memory is not a diagnosis. It is a way to postpone one. A query that scans an entire table will fill whatever memory you give it, and when the table doubles you will be back where you started, with a larger bill. The honest path is less convenient and usually cheaper: find the query, read the execution plan, fix the cause. The cause is one of three things.
Without the right index, the engine reads every row to find the ones you asked for. On a small table nobody notices. Then the table grows, and a lookup that should touch a few pages touches all of them, on every call, holding locks the whole time. The fix is often one line. Finding the right one line is the job.
The tables accreted one feature at a time. The same fact lives in three places and they disagree. Every report joins through a table that should not exist. You cannot index your way out of that. The structure has to change, carefully, without losing a row.
The application pulls a thousand rows to show ten, or makes one round trip per row instead of one per page. The database gets blamed for work the code asked it to do. We read both sides before we touch either.
Schema design
You will replace the front end. You may replace the framework, the hosting, even the language. The schema stays, and every application that ever touches the data inherits its choices. So we treat it with the weight it deserves: keys that mean something, constraints that make bad data impossible to insert rather than expensive to clean, names a new developer can read without a translator.
One of our standing rules: every string column is Unicode from the start. Not because every project needs it on day one, but because renaming a column is easy and changing its collation under production data is not. The cheap time to make that decision is before the first row exists.
That is the shape of most schema work. A small, dull cost paid now, or a large, interesting one paid later, at a time the database picks for you. We pay now.
Migrations
Changing a schema under a live system is the highest-stakes routine work in software. Our rules for it are strict and dull, which is the point.
The particulars
Azure SQL and SQL Server. That is the platform we know from the index up: execution plans, locking, collations, the parts vendors wave past.
Entity Framework migrations for schema change, applied from an Azure DevOps pipeline. Hand-written T-SQL where the generated query is not good enough, which happens, and we say so when it does.
A performance multiple. Nobody who has not read your execution plans knows how much faster your queries can get, and we have not read yours yet. We will tell you what we found, what it costs to fix, and what to expect. Numbers come after diagnosis, not before.
Start here
The report that takes four minutes. The page that times out at month end. The nightly job that now finishes mid-morning. A paragraph is enough, and we will tell you honestly whether it sounds like a database problem and whether we are the right people to look.