[jrdorn]

Hi! One of the authors here. We're using MongoDB to store caches A/B test results (among other things), which are deeply nested JSON objects. MongoDB let us develop features really quickly so its been a great choice so far for us. We're willing to add support for another data store if there's a lot of demand for it.

[ensignavenger]

Hi- thanks for making this and open sourcing it!

I would also suggest supporting an alternative to MongoDB. Postgres using jsonb is a great option.

I try to always use and support open source components, as open source provides much less business risk. Since MongoDB isn't itself open source, I would be hesitant to adopt it or a product that depends on it. Mongo also has a bad reputation...

I would definitely evaluate and likely use your product if it did not depend on MongoDB.

[gqewogpdqa]

Totally think it's good to have lots of options. PostgreSQL using JSONB however is a way to hurt your head. Using SQL to manipulate JSON is pretty painful. Why would MongoDB Community not be an ok choice? Unless you're planning on offering MongoDB as a cloud service, what would the concern be?

What's the bad reputation of MongoDB that you're concerned about?

Also, you seem to have a really strong bias against it - can you explain?

[ensignavenger]

> PostgreSQL using JSONB however is a way to hurt your head

Really? I have used it pretty extensively and like it... I don't do a lot of complex manipulations though, it might be a pain for some use cases.

> Why would MongoDB Community not be an ok choice?

MongoDB community is SSPL licensed, which is not Open Source. While I don't intend to offer a MongoDB hosting service, I want the option to fork the code and create (or pay some one else to fork the code and create) a hosting service for me to use. This is important because MongoDB Inc's business may not always align well with my business and my needs. (or they may just decide that they don't want to do business with me, maybe they go out of business or their business focus shifts or political pressures come to bear.) The option to create a viable community fork is critical to ensuring that the software remains viably usable. The business risk of relying on proprietary software is great. The more reliant you are on it, the bigger the risk.

> What's the bad reputation of MongoDB that you're concerned about?

Mongo has a long history with Jepsen test failures. See http://jepsen.io/analyses/mongodb-4.2.6 and the linked articles from that page. In addition, I have heard many confirmations of issues from folks who have used it in production.

> Also, you seem to have a really strong bias against it - can you explain?

I think I have explained my position above. I don't have any interest in Mongo or any of its competitors. I don't personally know anyone involved with it or any of its competitors (Though I have naturally had professional contact with some.) My strong preference, as previously stated, is for Open Source software. This preference applies broadly to all software, but especially to infrastructure software, and is by no means specific to MongoDB.

[pphysch]

What is painful about "SELECT json_result FROM test_results WHERE json_result -> 'data' -> 'foo' -> 'bar' = 'baz'"?

[sojournerc]

Nice project! PostgreSQL has excellent JSON support these days, including the ability to query nested fields which may be beneficial to your project.

[nrjames]

Honestly, I'd love to see it just use SQLite as a backend. If it's just storing results, that seems feasible and it would reduce the complexity of the tech stack.