Deepankar,

We at Percona, are not in position to provide a legal advise. I can speak only about myself and only hypothetically. So let’s say hypothetically I were to provide a SaaS service based on MongoDB. The SSPL license is kind of fuzzy about this, and I can make a conclusion either way. For some help there is SSPL FAQ
https://www.mongodb.com/licensing/server-side-public-license/faq
which covers this situation, to quote:
“What are the implications of this new license on applications built using MongoDB and made available as a service (SaaS)?
The copyleft condition of Section 13 of the SSPL applies only when you are offering the functionality of MongoDB, or modified versions of MongoDB, to third parties as a service. There is no copyleft condition for other SaaS applications that use MongoDB as a database.”

So it kind of gives assurance that I can provide SaaS application based on MongoDB and I am not required to open source code of my whole stack and my application. So I probably would be less worrying about this part.
However it is worth to remember that SSPL FAQ is NOT a part of license itself, so if it ever goes to a court, the court will consider only SSPL License text, not some outsides FAQs, so I would seek an additional confirmation from my legal team, that they are ready to deal with this case in a court if it is ever comes to it.

Lets say I provide a SaaS which uses MongoDB as a backend provider. This mongodb instance is then installed in a cloud instance for example for every customer seperately. And the same endpoint connects the application to Backend for functioning.

Would this fall under SSPL ?

Yep. I think if AWS fork is well governed it makes sense for community to cooperate instead of create many competing forks

“Since Elastic’s announcement, we’ve been collaborating with the AWS team to work towards a single distribution both organizations will take part in.”

https://logz.io/blog/truly-doubling-down-on-open-source-2/