Your data outlives your application. Frameworks get replaced and interfaces get redesigned, but the schema tends to stay, and decisions made early in it are felt for years afterwards. That’s why it’s worth getting a considered pair of hands on it.
Contact me about your database — designing a new one, or fixing one that’s become slow or awkward to change.
Databases I work with
- PostgreSQL — my default for relational data, and what I’d recommend to most businesses starting something new.
- MySQL — behind e-commerce and platform systems I’ve built and maintained.
- DynamoDB — for serverless systems on AWS, where the access patterns are known up front.
- ElasticSearch — for product search and full-text search over large bodies of content, where relevance and filtering matter more than storage.
- Redis — for caching and queues where speed is the point.
What database work usually turns out to be
When someone asks me to look at a slow database, the cause is rarely exotic. It’s usually a missing index, a query pattern issuing one statement per row, or a schema that fitted the first version of the product and hasn’t been revisited since. All three are cheap to fix once someone reads the query plans.
The other common request is changing a schema on a system that can’t go down. That’s a solvable problem, but it’s solved by planning the sequence of migrations carefully rather than by cleverness on the night.
I keep schema changes in version-controlled migrations that run as part of deployment, so the database moves with the application rather than by hand at the wrong moment.
Hire a freelance database developer
Contact me about designing, building or repairing the database behind your application.
