[ 07 — SYSTEMS & DATABASES ]
One reliable place for your data, designed, migrated and kept fast.
[ 01 — THE PROBLEM ]
What this usually looks like
Before
- The same customer exists in four files with three spellings, so every report is an argument.
- A query that took a second last year takes a minute now and nobody knows why.
- Backups run, and nobody has ever restored one.
- Getting a number out of the system means asking the one person who knows the export.
After
- A data model where each thing exists once, with the rules enforced by the database rather than by hope.
- Indexes, query plans and schema fixed on evidence from your real workload.
- Backups tested by restoring them on a schedule, with the restore time written down.
- Reports and dashboards your team can run themselves, built on the live data.
[ 02 — WHAT YOU GET ]
Deliverables, not deliverable-sounding words
A data model
Entities, relationships and constraints, documented, with the reasoning for the awkward parts.
Migration and cleaning
Existing data moved in, deduplicated and reconciled, with a report of everything that changed.
Performance work
Slow queries found, indexed and measured. Before and after numbers, not impressions.
Backup and restore
Automated, offsite, encrypted — and proven by an actual restore into a scratch database.
Reporting
Dashboards and scheduled reports, plus read-only access for the people who want to ask their own questions.
[ 03 — HOW IT WORKS ]
The steps, and how long each one takes
- 01
Look at what you have
3–5 daysThe current data, the queries that are slow and the reports people actually use.
- 02
Model it properly
1 weekDesign the schema, agree the awkward decisions, write the migration plan.
- 03
Migrate and reconcile
1–3 weeksMove the data, then prove the totals match before anyone relies on it.
- 04
Tune and index
1 weekAgainst the real workload. Expand, migrate, contract — no destructive change in one step.
- 05
Backups and handover
2–3 daysAutomated backups, a tested restore, and documentation your team can follow.
[ 04 — EXAMPLES ]
What people use this for
Consolidating spreadsheets
Years of separate files merged into one modelled database, with the reports rebuilt on top.
Rescuing a slow database
Finding why it got slow — usually a missing index, a bad query or a table that outgrew its design — and fixing it.
Reporting layer
A read replica and a dashboard tool, so analysts stop running heavy queries against production.
When the same customer exists in four files with three spellings, every report is an argument.
Modelled once, properly
We model your data once, migrate what you already have, and put the reporting and integrations on top of it. The constraints live in the database, so bad data is rejected at the door rather than discovered in a report six months later.
Backups are tested, not just scheduled
Backups are verified by restoring them into a scratch database on a schedule, and the restore time is written down. The question "how long would it take to get back" should have a number, not a shrug.
[ 05 — STACK ]
What we build it with
Chosen because they are boring, well supported and easy to hire for. Nothing here will be abandoned next year.
- PostgreSQL
- Prisma
- Python
- DuckDB
- Metabase
- Redis
- ClickHouse
[ 08 — FAQ ]
Systems & Databases: questions people ask
[ 09 — ALSO IN THIS PILLAR ]
Related services
Let's talk about systems & databases.
Tell us the problem. We will tell you what we would build, what it costs and how long it takes — before you commit to anything.