Database Management, Performance and Analytics

Databases that are fast, understood, and recoverable.

Where most database problems actually come from

Slow systems are usually not slow because of hardware. They are slow because a query that was fine against ten thousand rows is now running against ten million, because an index that would fix it was never added, or because a stored procedure grew a decade of special cases and nobody has been willing to touch it since.

The same is true of reporting. Most businesses are not short of data. They are short of a reliable way to ask it a question and trust the answer.

What we do

Proof

We rebuilt the entire data layer of a federal environmental-compliance platform and proved it faithful by diffing 243 compliance calculations across four instrument types against the original system, with zero regressions.

On a parcel logistics platform, we sharply reduced client-portal query times on a system customers used daily, and merged two companies' freight databases following an acquisition.

Further back, we built and led the database behind the U.S. Department of Defense's catalog of accredited security products, which ran in production across DISA with hundreds of cataloged products and real users across multiple divisions.

Platforms

Microsoft SQL Server and T-SQL, PostgreSQL, and MySQL. Reporting and analytics on top of any of them.

The approach that keeps working

Wherever the work allows it, we put the rules in data rather than in code. Pick lists, validation rules, thresholds, and rate tables belong in tables your staff can edit, read by a small engine that does not need changing when the business does.

It is the least fashionable idea we hold and the one that has aged best. Systems built this way survive staff turnover, because the knowledge is in a table somebody can read instead of in code somebody has to reverse engineer.

Who this is for

Businesses whose database is now load-bearing: it holds the record of what happened, the reporting the business runs on, or the calculations customers get billed from. Usually the trigger is that it has become slow, that nobody left understands it, or that an audit or acquisition has made both facts urgent.

Common questions

Our reports are slow. Is that a hardware problem?

Almost never. It is usually a query written against a much smaller table than the one it now runs on, a missing index, or a stored procedure that has accumulated years of special cases. Those are fixable without buying anything.

Can you work on a production database without taking it offline?

Yes, and most of this work has to be done that way. Changes are tested against a copy first and applied in a sequence designed so the system stays available.

Do you do ongoing maintenance, or only projects?

Both. Some clients want a defined piece of work finished and handed over. Others want someone who already knows the system available when something breaks or the business changes.

What happens to our data during a migration?

It is copied, never moved, until the new system has been verified against the old one. Your original stays intact and reachable throughout, and the rollback path stays open until you say otherwise.

Talk to us about your system

Every engagement starts with an assessment and a design you approve before anything changes. If you would rather talk it through first, that is free and there is no obligation attached to it.

Get in touch

Other things we do