Databases
Databases designed so the application does not have to lie.
Schema, indexes, migrations and access for Postgres-first products.
UI cannot rescue a confused schema. We design tables, keys and constraints so the application code stays thin and the reports stay true.
Postgres is our default. We will not introduce a new database because a blog post was exciting this week.
Benefits
What this changes in the business.
01
Fewer nulls that mean three things
States are explicit. ‘Empty’ is not a personality.
02
Queries that stay cheap
Indexes follow the questions you actually ask.
03
A history you can migrate
Files in git, not a production database edited by hand on a Friday.
Process
How the work moves.
01
Listen to the sentences
‘A booking belongs to a boat on a night’ is a schema. We write those sentences down.
02
Normalise, then bend on purpose
Denormalisation is a measured sin, documented.
03
Load a realistic slice
We test with ugly, duplicated, real-ish data — not ten tidy rows.
04
Put a fence around it
The app role cannot drop tables. Reporting cannot see secrets it does not need.
Technology
Tools we actually ship with.
- PostgreSQL
- Supabase
- SQL migrations
- Explain/analyse
- Logical backups
Questions
Straight answers.
Yes, with expand/contract migrations. Big-bang rewrites of live data are a last resort.
Places
Where this work sits.
Industries
Sectors that often need this.
Journal
Notes on the same craft.
Start a project
If every feature request starts with ‘the table cannot…’, the database is the project.
Tell us what you are building. We will reply with a clear next step — usually on WhatsApp.