If we start a .NET Core 3.0 project today, which will use database connection (for example ASP.NET Core Web API), is there still a place for non-async operations while talking to the database?

Or in other words: Should we always (by default) use async/await in Data Repository methods, while directly querying the database? I'm talking, using ToListAsync, FirstOrDefaultAsync?

I'm struggling to see any advantages by not using async operations while talking to the database.


The point of async is to allow the thread to perform other work while waiting on slower services/devices to repond.

So is your thread needed to perform other work?

  • If it is, then async/await is one way to free up your thread.
  • If it is not, then using async/await only makes your system more complicated without any real benefit.

If you want fast access by a limited number of threads its faster to query the database none async. But it will eat up threads fast so it should only be used when that extra performance is needed and when you know the method will only be used by a thread or two.

Like a background worker or similar, if the none async method is used from a web api method than you will run out of threads on the thread pool when many clients comnect and consume that web api method.

  • So technically, the mindset should be: always use async/await and return Task, unless - you REALLY need extra performance. Would you put it this way? – Adam Wojnar Dec 2 '19 at 22:07
  • And you know it will not be called from more than one or two threads. This is crucial, otherwise you will tank performance. – Anders Dec 3 '19 at 7:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.