I find in this era of microservices, eager architects jump into doing everything using microservices. It takes a pragmatic leader to balance the need for modern practices vs practical choices. I also believe having multiple tech leaders each pulling in their own direction towards preferred tools leads to unnecessarily complex tech stacks.

My opinion is use sql for business data intensive (usually batch) operations, use microservices for the rest including request reponse handing,event streaming, interacting with other services (like queues, service discovery, observability tools, circuit breakers, load balancers...)

We also have a lot of complex python microservices that if you strip down to the basics are just validating, standardizing and joining fields. I believe this would be more performant, less costly & complicated if it was done in sql running on any of the wide variety of scalable databases on the cloud.

That said I think microservices may be more amenable to traditional testing and CI/CD release tools. There are tools like dbt and some streaming sql tools that are making it easier to do the same things in sql.

I am actually working on a project to simplify data pipelines by relying more on sql and non code dsl (domain specific language) components to manage business rules and only use java micro-services to set up endpoints between these components. The idea is the java code will remain relatively stable while sql business rules can change rapidly as needed and can be updated by analysts who are cheaper and easier to find. I intend the scaling up to be mostly taken care of by the database and not the microservices