The stock market demands that the product have all the same stickers on as everybody else. But nobody is obliged to believe them. It may take quite a lot before anybody does, again.

The people working on the product are very smart and hard-working, but the problem they have set themselves is extremely complex, and possibly not solvable; or, even if ever solved, maybe not demonstrably so.

And, anyway, it is not what the customers actually want, although they might often need to convince their own management that they are getting it.

That is a very interesting take on the situation, especially because the tort of fraud starts from the opposite first principle: that customers may reasonably rely on the promises made by sellers.

The stickers come from organizations that are largely captured by vendors. Kudos to Jepsen for maintaining independence.

Would you say the same thing for company that sells parachutes?

There's a market for cheap, fast, easy, and good-enough reliability.

There are plenty of data stores like redis or memcached which promise and deliver exactly that, with known parameters, and they're awesome. I'm building an application right now where long-term data integrity doesn't matter too much (a dashboard will be down for a few minutes if we lost data), and they're the right way to go.

What I do grapple with is that MongoDB is none of those. When I've seen it used in projects, it was slow, hard, and expensive.

Because Mongo overpromises, it's hard to tell what its real limits are. You're quite likely to step on a landmine where something was promised but didn't come through. When that happens, you either have a huge amount of deep voodoo debugging, or perhaps it's a problem without a solution. That's almost always a lot more expensive than designing around psql in the first place.

And it's not particularly fast either.