When we reach for it
Always. Schema design, indexing and query plans are engineering decisions, and treating SQL as something an ORM generates on your behalf is how a system arrives at a query nobody wrote and nobody can fix.
SQL development
The language your data is actually queried in, and the one place where a bad decision is felt by every application that touches the database.
When we would argue against it
It is the wrong home for business rules that need to be tested, versioned and reviewed like the rest of the codebase. Logic buried in a stored procedure tends to be discovered rather than maintained.
What it looks like in delivery
We read plans before we add indexes, keep migrations in the repository beside the code that depends on them, and expect anyone senior on an engagement to be able to explain what a slow query is doing and why.
Where this appears on the site
Nothing on this site names it yet
We work in SQL, and no case study or service page currently published on this site prints it in its stack. Rather than describe an engagement you cannot check, this space stays empty until one does. Ask us and we will talk you through it directly.
Working in SQL?
Tell us what it is running, what it costs you today, and what you need it to do next. A senior engineer will tell you what we would keep and what we would change.