Home/Expertise/Database engineering
Database engineering
In long-lived business software the data layer holds the rules, the volume and the concurrency. It is also where a single change most often improves twenty screens at once.
Symptoms
Almost every database problem in a mature application is a decision that was correct at the time. A query that scanned a small table. A report that ran once a week. A schema that grew one column at a time because each addition was reasonable on its own.
Nothing broke. The data just kept arriving, and the margin quietly disappeared.
Scope
Making the system fast enough that people stop working around it.
Making the data layer something the next change can build on.
Method
Database performance work attracts guesswork more than any other kind. The discipline is in refusing to change anything until the cost is located.
Find the statements that actually consume the time, under a realistic load. The query everyone blames and the query costing the most are frequently different.
Read the plan. A scan is not automatically wrong and an index is not automatically right. Knowing why the engine chose what it chose is what makes the fix predictable rather than lucky.
One change, measured before and after. Several simultaneous changes make it impossible to know which one worked — and which one will cause the next problem.
The database usually outlives the application. That is why data-layer work holds its value even when the front end is eventually replaced — and why it is often the first sensible step in modernizing a system.
Questions
Most of our accumulated experience is on Microsoft SQL Server, which is where the enterprise applications we maintain have historically lived.
The engineering approach — reading execution plans, understanding what the optimizer is doing, and changing the smallest thing that fixes it — carries across relational platforms. If you are on something else, tell us which and we will be straight about how much of that is transferable.
Often, yes. Indexing, statistics, query rewrites inside stored procedures and schema-level changes can all be done behind an unchanged application.
It is usually the first thing to try, because it avoids a release — and a fix that does not need a deployment window can be in production the same week.
Whichever costs less over time. An index is cheap to add and carries an ongoing write cost; a rewrite is more work once and free afterwards.
The wrong answer is adding indexes until something improves. That is how databases end up with more index than table, and how a read fix becomes a write problem.
Yes, and the first honest step is establishing what it would actually cost.
Data migrates far more easily than the logic around it. Stored procedures, platform-specific SQL and assumptions about locking behaviour are where the effort concentrates — and they are rarely in the initial estimate.
Next step
Tell us what the application does, roughly how much data it holds, and where it hurts. Performance problems are usually diagnosable long before they are expensive.
