Build

Database Development

Schema design, migrations, query performance and the reporting layer on top. Usually the cheapest performance work available, because the slow part is almost always one query nobody has looked at.

Typical work
1 to 6 weeks
Access needed
A restored copy
Downtime
Planned: essentially none
Deliverable
Measured before and after
Engines
Postgres, SQL Server, MySQL, Oracle
How it works

Three bottlenecks, and none of them is the server.

When an application is slow, the instinct is to buy more hardware. In our experience the time is going somewhere much more specific, and much cheaper to fix.

Three bottlenecks, none of them the server. We find them before anyone buys more hardware.
What we build

Three things this usually turns out to be.

Performance

The page that
takes eight seconds

Read the execution plan, fix the query or add the index, measure again. One change at a time so the cause is never in doubt.

Typical result: seconds becoming milliseconds
Structure

A schema that grew
by accretion

Redesigned so that the next feature does not fight it, migrated online, in steps, with a rollback written down before anything runs.

Typical result: changes that stop being frightening
Reporting

Analysts querying
production directly

A read replica and defined views, so that reporting cannot take the business down and two dashboards cannot disagree.

Typical result: reporting that is safe to run
The stack

What we reach for, and why.

The engine matters less than the measurement. We will not recommend migrating databases to solve a problem that an index would fix.

Engines
PostgreSQLSQL ServerMySQLOracle
Performance
Execution plansIndex designPartitioningQuery rewriting
Change
Online migrationsFlywayLiquibaseBatched backfills
Reporting
Read replicasMaterialised viewsDefined metrics
Operations
Backup and restore drillsReplicationConnection pooling
How to buy it

The work is the same. The shape of the deal is not.

Database work is bought under any of the three engagements, though it is most often a short, sharp forward deployed engagement.

Honestly

Usually the cheapest week you will spend.

Come to us when

Good fit

  • The application is slow and everyone assumes it needs a bigger server.
  • A schema that fights every new feature.
  • Reporting numbers that disagree depending who ran them.
  • A migration nobody is brave enough to run.
Go elsewhere when

Poor fit

  • You need a data engineer building pipelines and a warehouse. Different job.
  • You want somebody to run the servers. That is managed hosting.
  • The application asks for data badly and you will not change it.
Questions

Before you book the call.

Yes, and we prefer to. A restored copy with realistic volume is enough for almost all of this. We do not need write access to your production database and will not ask for it.

Planned downtime, essentially never. Index additions and most migrations run online on modern engines. Where a change genuinely needs a window, you will know well in advance with a rollback plan written down.

Then we say so. Roughly a third of the time slow queries are a symptom of an application asking for data badly rather than a database serving it badly. The audit tells you which, and that answer alone is worth the week.

Yes, and we would rather build it properly than let analysts query production directly. Read replicas, defined views and written definitions so that two people asking the same question get the same number.

Next step

Send us one slow query. We will tell you what it is costing you.

Thirty minutes. Often the honest answer is that a week of this is worth more than a quarter of application work.