Technology
DatabasesPostgreSQL, MySQL, Redis
The database stack we reach for, the trade-offs we name, and when we use something else — PostgreSQL as the default, MySQL for the team that already runs it, Redis for the cache and the queue, with the choice made against the query, the data and the deploy.
What we use it for
PostgreSQL as the default — the right answer for 80% of the products we build, with the best tooling, the best extension ecosystem, the most predictable performance, and the most engineers who know it. MySQL for the team that already runs it or the workload that fits it. Redis for the cache and the queue. MongoDB for the document use case. Elasticsearch for the search.
We extend the stack with the extensions the product needs — pgvector for the embeddings, PostGIS for the geospatial, TimescaleDB for the time series. The choice is made against the query, not the language.
When we choose it over the alternative
PostgreSQL is right when the product is relational, the query pattern is well-known, and the tooling matters. MySQL is right when the team is already strong in it, the workload is read-heavy, and the deploy is a managed MySQL. Redis is right for the cache, the queue, the rate limit and the session store.
The right answer depends on the query, the data and the deploy. We will say so on the call, with a written rationale for the choice and the trade-offs named.
When we do not choose it
We do not choose PostgreSQL when the query pattern is genuinely a document pattern, a search pattern or a time-series pattern — those are the cases where MongoDB, Elasticsearch or TimescaleDB is the right answer. We do not choose MySQL when the team is not strong in it and the workload does not demand it.
We also do not choose the default when the deploy constraint (a managed service, a specific region) makes the alternative the right answer. The default is the right answer for the team that can run it, not for the team that has to learn it on the way.
Frequently asked
The questions the team asks
- PostgreSQL or MySQL?
- It depends on the team and the workload. PostgreSQL is the right default for most products, with the best tooling and the most predictable performance. MySQL is the right answer when the team is already strong in it, the workload is read-heavy, and the deploy is a managed MySQL.
- When do you add a second database?
- When the query pattern does not fit the primary. A search workload on top of PostgreSQL becomes a case for Elasticsearch. A cache layer on top of PostgreSQL becomes a case for Redis. A document workload on top of PostgreSQL becomes a case for MongoDB. The second database is justified by the query, not by the trend.
- How do you handle the migration?
- A written migration plan with named owners, a test cut with a small subset of records, a parallel run for at least one full business cycle, and a recovery path. The migration is staged, with the old system decommissioned in its own time, after the new one is trusted in production.
Have a project in mind?Let’s scope it together.
Tell us the outcome you need. You get an approach, a rough timeline and next steps within one business day.