Proposal: Drop MongoDB who is no longer open source

[pombredanne]

SUMMARY

MongoDB changed its license from the open source AGPL to a the proprietary SSPL in October 2018.
I suggest to drop using MongoDB and replace this with another database.

[bigmstone]

@pombredanne Thanks for the proposal.

You can appreciate the considerable cost this would create - so this one is a bit tougher than, say, removing/changing a less pervasive library. I suspect one of the following to happen over the next couple of years:

1. If MongoDB is negatively affected by the move and the move does not prevent cloud providers from moving forward (ala AWS w/ their 3.6 compatible DB offering) it might revert its decision
2. If the community sees reason to keep the Mongo API going we could see a fork of the last available AGPL Licensed Mongo Version.
3. No one will much care since SSPL is AGPL + one amendment that affects SaaS offerings OF the database.

The key phrase for me in the amendment is:

If you make the functionality of the Program or a modified version available to third parties as a service...

So we will keep an eye on this as it progresses, but we're a small team with limited resources and right now I don't see the incentives aligned to change the database over unless we get that contributed from the community. Which would then take the discussion into another direction.

I won't close this for now as I think it would be interesting to gauge the community's interest.

Note: IANAL, so don't believe any interpretations of their license that I provided here.

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically marking is as stale. If this issue is not relevant or applicable anymore (problem has been fixed in a new version or similar), please close the issue or let us know so we can close it. On the contrary, if the issue is still relevant, there is nothing you need to do, but if you have any additional details or context which would help us when working on this issue, please include it as a comment to this issue.

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically marking is as stale. If this issue is not relevant or applicable anymore (problem has been fixed in a new version or similar), please close the issue or let us know so we can close it. On the contrary, if the issue is still relevant, there is nothing you need to do, but if you have any additional details or context which would help us when working on this issue, please include it as a comment to this issue.

[kgrvamsi]

Proposal: Architecture on having a Unified DataLayer

Note: I might be wrong in understanding the architecture of stackstorm but with some research and work experience around stackstorm i'm adding my views here on how we can try to resolve this issue having no dependency on any db.

Notes

1. Stackstorm model should support both AGPL and SSPL so that even a vendor changes its business model from AGPL to SSPL , Stackstorm as a application don't need to worry about the support.
2. Stackstorm with unified data layer now it have the capability to stretch the arms to support cloud centric saas platforms running on cloud (AWS, AZURE etc)
3. Other supporting services don't need to worry about the support for edge conditions until the underlaying db is not matching the base standard of mongodb functionalities as its been a base db that's been supporting stackstorm all these years.

[arm4b]

FYI Mistral that uses PostgreSQL will be removed in next stackstorm 3.3.0 release, per https://docs.stackstorm.com/roadmap.html in favor of Orquesta, self-grown workflow engine and replacement of Mistral.
See https://stackstorm.com/2020/04/30/stackstorm-v3-2-0-released/ which highlights that too.

Unified Data Layer which brings multi-DB engine support is nice, however any generalization and new layers may lead to performance issues. Our experience developing for StackStorm performance and throughput requirements and optimizing it led us in other direction by using less abstraction layers.

For example, implementation-wise, st2 in some DB operations even moved out of ORM-like generic approach (we're using https://pypi.org/project/pymongo/ ATM) and started relying on various MongoDB functionality specifics for performance reasons and optimizations.

To give more context, please review the following problems related to performance, most of them are DB-specific:

• https://github.com/StackStorm/st2/issues?q=is%3Aopen+is%3Aissue+label%3Aperformance
• https://github.com/StackStorm/st2/issues?q=is%3Aissue+label%3Aperformance+is%3Aclosed
• https://github.com/StackStorm/st2/pulls?q=is%3Aopen+is%3Apr+label%3Aperformance
• https://github.com/StackStorm/st2/pulls?q=is%3Apr+label%3Aperformance+is%3Aclosed