Running your system in smaller, independently deployable and isolated modules allows you to use whatever technology that can suite your problem the best for that particular business domain.

Since each service is self-contained, and the only way in which it can be communicated with is via the publicly-defined interface of the service, it means that pretty much whatever happens behind the public interface is the sole business of your service! So, in theory, you are free to use whatever technology that your tech-crazed heart desires!

Why would you want to do this?

There's a very (I think) over-used expression in the software world that says: "if all you have is a hammer, everything looks like a nail".

Sometimes you are using the incorrect tool for the job that you are trying to do. In a monolithic codebase, however, it can be difficult to change since you may find that you would need to change everything at once which would be too risky and time-consuming. Since microservices are small, you could experiment by changing the underlying technology for a portion of your system while leaving the remainder of the system unchanged. You can then test this thoroughly in your staging environment and determine whether or not it does better than the existing technology.

This is not necessarily just good for trying new technologies out and fixing a technical problem, but it can also help your business by expanding the pool of developers to hire from.

If, for example, your company does only Java for the backend, but good Java developers are difficult for your company to find and employ, and the company has seen that there are a lot of good Python developers in the market, then you could, again - in theory, now start to hire python developers!

The potential problems with this

Using new technology - whether that is a new framework, language, database - comes with more overheads than simply you, sitting at your computer and learning to use it.

There will be quirks with it, hidden gotcha's that will come out of the woodwork when you least expect it. The grass is not always greener on the other side of the fence. Are the risks worth the potential rewards?

What about other people learning the new tech? Are the other developers willing to put in the time and effort to become familiar with it?

How about maintenance? Many companies have DBA's that are familiar with the types of databases they use. Adding a new one to the company will require involvement from them too.

What about down-stream reporting? How will the new database fit into the existing business processes?

Adding new technology to your system will require some potentially big shifts in your organization in order to be successful!

It's good to have the option

Even if you never use a different technology for a particular service,
it's still really good to be able to if needed! Even if in the future the system becomes legacy and needs to be rewritten, at least it can now be done in isolated portions rather than a big bang approach often needed by large enterprise systems.