Data & Analytics

Database Consulting

Slow queries dragging your application down? A migration you keep postponing? I find the real problem in your database and fix it.

Database consulting is the work of making the database under your application fast, sound, and safe to grow — diagnosing why it's slow, fixing the design that holds it back, and moving it without breaking anything.

Your database is the floor everything else stands on. When it's slow, every page is slow. When it's modelled wrong, every new feature gets harder to build than the last one. And when it fails, the business stops — not a feature, the whole thing. Most owners don't think about the database until one of those three things happens. By then it's already costing them customers, developer time, or sleep. That's usually the week they look for a database consultant — and the week I get the call.

What does database consulting actually cover?

The work takes a few recognisable shapes, and most projects are one of them named in your own terms.

The reports that time out. A page that used to load instantly now spins. A dashboard that worked at a thousand records crawls at a million. I find the queries doing the damage, rewrite them, and add the indexes the database needs to answer fast — then measure so you can see the difference, not just take my word for it.

The architecture that outgrew the idea. The data model that was fine for your first version is now fighting your current load. I reshape the schema so it fits how the business actually works today, without a rewrite from scratch and without a weekend of downtime to do it.

The move you've been putting off. From MySQL to PostgreSQL. From a server in a closet to the cloud. Merging two databases after an acquisition. These are the projects that go wrong quietly, so I plan them with a rollback ready and validate the data on the other side before anyone calls it done.

The design question with no in-house answer. How should this data be modelled? Normalise it or not? How do you store something that's really a stream of events over time? Sometimes the whole job is one good afternoon of decisions made by someone who has made them before.

How does a database project work?

First, a thirty-minute call. You tell me what's actually wrong — the slow page, the migration on the calendar, the design you're unsure of. I'll tell you honestly whether it's a database problem at all, because sometimes it isn't, and what it would take to fix. Free, usually this week.

Then I look at the real thing. Not a questionnaire — your actual query logs, your actual schema, your actual numbers. I find where the time goes and where the design fights you, and I come back with a short list of fixes ordered by what buys you the most for the least risk.

Then the fixes get made. I do the work — rewriting queries, changing indexes, reshaping the schema, scripting the migration — or I guide your developers through it if you'd rather keep it in-house. Either way you watch it happen, you don't just receive a document.

Then we prove it worked. Every change is measured against where you started, so an improvement is a number you can see. You get a plain-language write-up of what changed and why — so the next person who touches the database isn't starting blind.

What you get

A database you can measure. Before-and-after numbers on the queries that mattered, not a vague promise that things are "optimised". You see exactly what got faster.

A schema that fits the business. A data model shaped around how your operation actually runs — so the next feature your team builds is easier, not another fight with the structure.

A migration that lands clean. When the job is a move, you get a tested plan, transformed and validated data, a rehearsed cutover, and a rollback ready in case — so the change happens without losing data or a night's sleep.

A written record. Plain-language documentation of what was done and the reasoning behind it. Your developers can maintain and extend the work without me, and without guessing.

Is database consulting right for you?

A good fit if:

  • Your application is slow and you suspect — or have been told — the database is the cause
  • You have a migration ahead and would rather it be planned than improvised
  • Your team builds the product well but has no dedicated database specialist
  • You're designing a new application's data model and want it done right the first time
  • You'd rather pay once for a sound structure than keep paying in developer time for a shaky one

Not a fit if:

  • Your application is slow for reasons that aren't the database — I'll tell you on the first call if that's what I see, but if you already know the bottleneck is elsewhere, this isn't the work you need
  • You want a long document of recommendations that nobody will action — I fix things or guide a team that will, I don't write shelf-ware
  • You're shopping for the cheapest possible hourly rate; careful database work is not where to save money, because the mistakes are expensive and quiet
  • Your project is 3D games, casino software, adult content, or adversarial scraping

Frequently asked questions

What databases do you work with?

Primarily PostgreSQL and MySQL or MariaDB — those cover most business applications. I also work with the managed cloud versions (AWS RDS, Google Cloud SQL, Azure Database), and with MongoDB, Redis, and Elasticsearch when a project genuinely needs them. PostgreSQL is the one I reach for first when the choice is open, because it handles complex data and growth with the fewest surprises later.

My application is slow — can you help?

Usually, yes. A slow database is one of the most common reasons an application drags, and it's often the hidden one. I start by analysing your queries to find where the time actually goes, then work through indexing, schema changes, and caching. If the slowness turns out to live somewhere other than the database, I'll tell you that plainly rather than bill you to chase the wrong thing.

Can you migrate our database without downtime or data loss?

That's the goal of every migration I take on, and it's why I plan rather than improvise. A migration project includes risk assessment, scripts to transform the data, validation that everything arrived intact, a rehearsed cutover, and a rollback ready if something looks wrong. Most moves can be done with little or no downtime — the honest answer depends on your setup, which is exactly what the first call is for.

Do you offer ongoing database support?

Yes. Some clients want a one-off fix; others want someone keeping an eye on things over time — monitoring, routine maintenance, performance tuning as the data grows. Both work. We can decide which fits once I understand how your database is used and how fast it's changing.

Will you fix things yourself or just tell my team what to do?

Whichever serves you better. I'll rewrite the queries, change the indexes, and script the migration myself — or I'll guide your developers through doing it, so the knowledge stays in-house. Plenty of projects are a mix: I handle the tricky parts and walk the team through the rest. You decide based on what your team has time and appetite for.

Let's talk

Tell me what your database is doing to you — the page that times out, the migration on the calendar, the design you're not sure about. A thirty-minute discovery call is free: no deck, no sales, just a straight answer on whether I can help and what it would take.

Want to talk it through?

Let's scope your project.

Book a discovery call