The data model outlives the application on top of it.
Applications get rewritten every seven years. The data model tends to survive all of them, which is why it deserves more design attention than it usually receives and why fixing it later is so expensive.
- First question
- What can your team operate?
- Second
- What can you hire for locally?
- Third
- What does the existing estate already run?
- Rarely decisive
- Benchmarks and framework fashion
The right technology is the one you can still run in five years.
Most performance problems we are called in to fix are modelling problems wearing a performance costume. Adding hardware or caching around a poor schema buys time; it does not change the trajectory.
We are equally comfortable in relational and document stores, and we will argue for the boring relational option more often than not, because most enterprise data is relational whether or not the application acknowledges it.
Every engagement is delivered with your engineers in the repository from the first week, so the knowledge accrues internally, not leaving when we do. You own the code, the pipelines and the documentation regardless of how the engagement ends.
If you are weighing a decision and want a second opinion instead of a proposal, we are happy to give one.
PostgreSQL, MySQL & MongoDB
PostgreSQL is our default for new work: it handles relational, JSON, full-text and geospatial workloads competently, which removes a great many reasons to add a second store.
- Schema design, normalisation and deliberate denormalisation
- Query tuning, indexing strategy and execution plan analysis
- Replication, partitioning and high availability
- MongoDB where the document model genuinely fits the access pattern
Microsoft SQL, SQLite & Realm
SQL Server across Microsoft estates, and embedded stores where an application needs to keep working without a network connection.
- SQL Server design, tuning and Always On availability
- T-SQL and stored procedure modernization
- SQLite and Realm for offline-capable mobile applications
- Migration between SQL Server and PostgreSQL
Redis, Elasticsearch & big data
Caching and search layers, used to solve specific problems, not as a default architectural garnish.
- Redis caching, session storage and queueing
- Elasticsearch and OpenSearch for search and log analytics
- Spark and distributed processing where volume justifies it
- Data lake and warehouse design
Pandas, NumPy & Scala
The processing layer between raw data and something a business can act on — pipelines that run reliably on a schedule, not notebooks that run when someone remembers.
- ETL and ELT pipelines with proper orchestration
- Data quality validation and reconciliation
- Feature engineering for machine learning
- Migration from spreadsheet-based processes
Need engineers on your own team instead?
Named individuals you interview, on monthly rolling terms. Each of these has a page explaining what separates a good hire from an average one in that stack.