SQL: Parallel Programming In TSQL: Is It In Our Future?

SQL: Parallel Programming In TSQL: Is It In Our Future?

Upcoming processors are likely to have even more cores than now. Have you ever tried to write multiprocessor-style code? A friend of mine recently said that he learned some of this style of coding but later when he came back to it, he realised how much he thought he knew but didn’t.

For languages like T-SQL, we don’t have inherent support for multi-threading. In fact, the only trace I can see of this in T-SQL today is the ability to have multiple readers on a service broker queue.

In general, we haven’t needed this because SQL Server systems constantly have many requests thrown at them concurrently anyway and there is a natural style of parallelism happening.

But does T-SQL need parallel code options?

If languages need to evolve, I think it’s important that wherever possible, that it’s the languages that work out how to parallelise the code, not the developer. I often mention to people that in one interview I did with the late Dr Jim Gray, he noted that people learning to write multithreaded code tend to go through three phases:

1. when it all just looks like magic and you don’t understand any of it.
2. when you think you understand it.
3. when you get wise.

That’s very insightful and has stuck with me ever since. 

I’ve written a bunch of multithreaded code over the years and my experience exactly parallels (pun intended) the phases he described. Getting it right is much, much harder than it looks.

Current SQL Server parallelism support

SQL Server supports:

  • Parallel query execution (Query Processor decides)
  • Parallel plans (multiple threads driven by cost-based optimizer)
  • Batch mode parallelism
  • Parallel index operations

…but there is no PARALLEL keyword or any asynchronous SQL block.

However:

  • SQL Server Service Broker allows asynchronous message processing.
  • SQL Server Agent Jobs can run concurrently.
  • T-SQL does not allow async/parallel programming inside stored procedures.

ANSI SQL lack of support

ANSI/ISO SQL has:

  • No async
  • No await
  • No parallel blocks
  • No threading or concurrency primitives

SQL is declarative. The thinking is that you tell the engine what you want, not how to run it. Parallelism is left entirely to the query optimizer/runtime.

PostgreSQL support

I’ve been doing quite a bit of work with PostgreSQL again lately, and it offers:

  • Parallel scans
  • Parallel joins
  • Parallel aggregates
  • Parallel index builds

…but again, not via SQL syntax.

Summary

I’ve also looked through many other SQL variants and currently don’t see any constructs for parallel support in the SQL language.

I can imagine a number of situations where I wish T-SQL had parallel code support. For example, I’d like to be able to start a number of processes (or even stored procedures), have them all run concurrently, and to be able to wait for them all to finish. The closest I have to that is the Agent Job system but that’s a long way from what I’m keen to see.

Do you have any situations where you wish you could launch T-SQL code asynchronously, and in parallel?

2025-12-22