If you aren't already (1) telling Claude Code which flavor of SQL you want (there are several major dialects and many more minor ones) and (2) giving it access to up-to-date documentation via MCP (e.g. https://github.com/arabold/docs-mcp-server) so it has direct access to canonical docs for authoritative grounding and syntax references, you'll find that you get much better results by doing one or both of those things.

Documentation on features your SQL dialect supports and key requirements for your query are very important for incentivizing it to generate the output you want.

As a recent example, I am working on a Rust app with integrated DuckDB, and asked it to implement a scoring algorithm query (after chatting with it to generate a Markdown file "RFC" describing how the algorithm works.) It started the implementation with an absolute minimal SQL query that pulled all metrics for a given time window.

I questioned this rather than accepting the change, and it said its plan was to implement the more complex aggregation logic in Rust because 1) it's easier to interpret Rust branching logic than SQL statements (true) and 2) because not all SQL dialects include EXP(), STDDEV(), VAR() support which would be necessary to compute the metrics.

The former point actually seems like quite a reasonable bias to me, personally I find it harder to review complex aggregations in SQL than mentally traversing the path of data through a bunch of branches. But if you are familiar with DuckDB you know that 1) it does support these features and 2) the OLAP efficiency of DuckDB makes it a better choice for doing these aggregations in a performant way than iterating through the results in Rust, so the initial generated output is suboptimal.

I informed it of DuckDB's support for these operations and pointed out the performance consideration and it gladly generated the (long and certainly harder to interpret) SQL query, so it is clearly quite capable, just needs some prodding to go in the right direction.

Haven't heard of docs-mcp-server, but there is the very popular Context7 with 23k Github stars and more active development:

https://github.com/upstash/context7

Great suggestion, thank you!

I bet it highly depends on the work you do.

It is very useful for simpler tasks like writing tests, converting code bases etc where the hard part is already done.

When it comes to actually doing something hard - it is not very useful at least in my experience.

And if you do something even a bit niche - it is mostly useless and its faster do dig into topic on your own that try to have Claude implement it.

Even when I hand roll certain things, it still nice to have Claude Code take over any other grunt work that might come my way. And there are always yaks to shave, always.

Claude Sonnet 4 is very good at generating Cypher queries for Neo4j

Try getting Claude to write a style guideline based on some of your existing manually coded work and then see if it improves using that in context.

I found claude sonnet 4 really good at writing SQL if you give it a feedback loop with real data. It will research the problem, research the data, and improve queries until it finds a solution. And then it will optimize it, even optimize performance if you ask it to run explain plan or look at pg_stat_statemnts (postgres).

It's outrageously good at performance optimization. There's been multiple really complex queries I've optimized with it that I'd been putting off for a long time. Claude code figured the exact indexes to add within seconds (not ones I would have got easily manually).

The trick is to have it run it through sqlglot and correct the errors.

This kind of thing is a key point. Tell Claude Code to build the project, run linters, run the tests, and fix the errors. This (in my experience) has a good chance of filtering out mistakes. Claude is fully capable of running all of the tools, reading the output, and iterating. Higher level mistakes will need code written in a way that is testable with tests that can catch them, although you probably want that anyway.