Query plans taught one engineer more about AI cost control than any prompting course could. Yaniv Leven spent years deep in SQL execution plans, chasing slow joins and bloated queries. Now they are applying those exact instincts to a brand new problem: shrinking the cost of AI prompts.
They wrote about the shift on Medium, and the resemblance caught them off guard. Prompt engineering did not feel like a new career. It felt like the same job wearing a different syntax. I read the post twice because I had never seen the connection stated so plainly. It changed how I think about hiring for AI teams.
Quick version, if you are short on time: SQL tuning and prompt cost optimization use the same core skill. You need to understand the system, build a mental model of it, then optimize at scale. Everything below breaks that idea into steps you can actually use.
Here’s the idea driving the whole post: SQL optimization and prompt engineering both come down to one question. Do you understand the system well enough to build a model of it, then optimize at scale? Swap “query planner” for “context window” and the logic barely changes. That is the same discipline wearing different clothes, applied to a different kind of engine.
📋 The old way: tuning queries
Database engineers built a whole toolkit around that question, and most of it still applies today.
- Read the execution plan before touching a slow query.
- Add an index instead of rewriting the entire schema.
- Estimate row cost before the query ever hits production traffic.
- Watch for full table scans hiding behind an innocent-looking “SELECT *”.
🤖 The new way: tuning prompts
Prompt engineers are rediscovering the same toolkit, just with new vocabulary attached to it.
- Read the token breakdown before touching a slow, expensive prompt.
- Cache repeated context instead of resending it on every single call.
- Estimate token cost before the prompt ever runs at scale.
- Watch for bloated system prompts hiding behind an innocent-looking “just add more context”.
Line up those two lists and the pattern jumps out immediately. Every SQL habit has a direct prompt engineering twin. The author’s real point is that this is not a brand new skill people need to learn from zero. It is a transfer, and transfers move faster than starting cold. That is genuinely good news for anyone who spent a decade buried in query optimizers and wondered if that experience still counts for anything.
Here is how to put that transfer to work, step by step.
- Map the system before you touch anything. For SQL that means the schema, the indexes, and the query planner. For prompts that means the model’s context window, the system instructions, and everything that gets sent on every single call. You cannot optimize a system you have not mapped first.
- Put a price on every unit of work. SQL people track row cost and I/O. Prompt people should track cost per token and cost per completed task, not accuracy alone. You cannot optimize what you never measured, and this step is the one people skip most often.
- Cache what repeats. Materialized views saved database teams a decade of redundant computation. Prompt caching and shared system prompts do the same job for AI teams right now, and the savings compound fast at scale.
- Treat every optimization as a hypothesis, not a fix. SQL engineers rerun EXPLAIN after every change to confirm the plan actually improved. Prompt engineers should rerun their cost and quality checks after every trim, because a shorter prompt that breaks accuracy is not really an optimization.
One commenter on the original thread joked about writing “the most optimized prompt to deliver the most optimized SQL.” That line is honestly the perfect one-sentence summary of where these two skills are headed. The border between database tuning and AI cost tuning keeps getting thinner, and it might disappear completely within a couple of years.
If you have spent years in SQL and are eyeing prompt engineering, do not treat it as a reset button. Bring your query-tuning brain with you. Carry over the habit of measuring before changing, the instinct to cache instead of repeat, and the discipline of pricing every operation before it ships. Then go read the original post, because the author lays out the full journey in more detail than a summary can capture. It is worth seeing how far you can push the analogy yourself.
Optimized SQL for a long time now started dealing with prompt engineering cost optimization. wrote my first blog about the experience
by u/Spiritual-Kitchen-79 in PromptEngineering