Database design & development
that stays honest at scale.
Schemas, queries and migrations that stay fast and honest as the data grows.
- — Pages slow down as the table grows and nobody knows which query
- — The same field is stored in three places and they disagree
- — Migrations are feared and run manually at midnight
The work should
change the numbers.
The schema outlives the framework. Interfaces get redesigned every few years; the data model you choose in month one is still shaping what is easy and what is impossible in year five.
We design schemas that make invalid states unrepresentable — constraints, foreign keys and types doing the work that application code usually ends up doing badly. Then we make them fast, with indexing based on measured query plans rather than intuition.
For existing systems, this work is usually remedial: find the queries costing you the most, fix them, then repair the modelling decisions that caused the pattern in the first place.
What the engagement
actually contains.
Data modelling
Normalisation where it protects correctness, denormalisation where it earns performance, with the reasoning recorded.
Constraint design
Keys, checks and types that make bad data impossible to insert rather than merely unlikely.
Query and index tuning
Execution plans read properly, indexes added deliberately, and the slow-query log turned into a work queue.
Safe migrations
Zero-downtime, reversible migration patterns with backfills that do not lock production tables.
Reliability and recovery
Backup verification, point-in-time recovery, and a restore actually rehearsed rather than assumed.
Reporting separation
Read replicas or an analytical store so heavy reporting stops competing with live traffic.
- Documented schema with entity diagram
- Migration scripts with rollback paths
- Index and query optimisation report with before/after timings
- Backup and verified restore procedure
- Reporting replica or analytical pipeline
- Data dictionary for the wider team
- Pages slow down as the table grows and nobody knows which query
- The same field is stored in three places and they disagree
- Migrations are feared and run manually at midnight
- Nobody has ever tested restoring a backup
What usually went wrong
before we were called.
- 01Letting application code enforce rules the database should guarantee
- 02Adding indexes by intuition instead of reading execution plans
- 03Running heavy reporting against the same instance serving customers
- 04Never testing a restore, so the backup is a belief rather than a fact
- p95 query time on hot paths
- Slow query count per day
- Migration duration and lock time
- Verified restore time
2–4 weeks remedial; 4–8 weeks for a full model rework
What week one
actually looks like.
The slow query log turned into a ranked work queue, execution plans read for the worst offenders, and a restore rehearsed to confirm the backups are real.
- Read access to production or a recent dump
- Query volume and growth expectations
- Application repository access
- A window for migration work
- Ongoing database administration, unless retained
- Hosting or managed database costs
- Business intelligence modelling
- Data entry or cleansing
Scope boundaries stated up front rather than discovered in a change request.
Four stages, visible throughout.
Model
The domain, data and permissions written down before any interface exists, because the schema outlives every screen above it.
Prototype
Flows and states tested as a clickable prototype, so the expensive disagreements happen in Figma rather than in code.
Ship in slices
One workflow at a time, in production, with tests and observability included in the definition of done.
Operate
Release tooling, monitoring and a documented handover so your team can run and extend what we built.
Where this has paid off.
One dashboard instead of nine spreadsheets.
A custom admin platform gave a new fund a single, trustworthy view of its portfolio and reporting.
Less admin. More operating leverage.
Integrating a scattered toolchain behind one internal app removed the copy-paste work between systems.
Database design & development, answered.
PostgreSQL is the default recommendation for the overwhelming majority of business systems: correct, fast, extensible and boring in the best sense. We reach for specialised stores — search, time-series, analytical, vector — as additions to it, not replacements for it.
Almost always, and it is where we start. A handful of missing indexes, an N+1 query pattern and one unbounded query typically account for most of the pain. We measure, fix the top offenders, then discuss modelling changes with evidence in hand.
Expand-and-contract: add the new structure, backfill in batches, write to both, switch reads, then remove the old structure. Each step is reversible on its own, which is what makes the sequence safe.
SaaS & custom software
Product engineering for the system your business runs on and no vendor sells off the shelf.
API & third-party integrations
CRMs, ERPs, payments and internal tools connected so the data stops being re-typed by people.
Speed & performance optimisation
Core Web Vitals, bundle size and server response times taken seriously enough to move revenue.
E-commerce platform migration
Wix, Magento or bespoke to Shopify and back again — moved without losing orders, URLs or rankings.
Make database design & development useful.
Bring us the hard thing. We will bring a point of view, a senior team and a clear next step.