2 ms·

I built something similar years ago. These are terribly hard to build, so I did a bit of digging. 1: This appears to be backed by a French company called Linag

I built something similar years ago. These are terribly hard to build, so I did a bit of digging. 1: This appears to be backed by a French company called Linagoria. I don't know much about the company, but they've been around for a bit. 2: I experimented with Mongodb for the similar product, and it turned out to be very unreliable. A lot can change since I used Mongodb, but in general, I'm weary of any product that uses it unless there's an expectation that data is lossy. (Which was the problem Mongodb had at the time: Their CTO only wanted to target lossy data use cases, but the people interested in using Mondodb wanted a database that was easier to use than SQL.)

evolve2k 1y ago
I’ve had similar warnings from multiple very senior devs to never go near mongo. So better explain that choice if you’re wanting adoption. Reliability was the concern.
- gwbas1c 1y ago
  At the time (2010), MongoDB was intended (from the creators) for handling high volumes of data where some loss was tolerable. What happened was that its document model, and flexible index model, made it very attractive as an easy-to-use database. I used to call it the "Visual Basic" of databases. I think the less technical people in marketing latched on to how a lot of people found MongoDB easier to work with, and there was a lot of selling to people who it shouldn't have been sold to. The problem was that the lossiness nature of MongoDB didn't rear it's ugly head until deep in a project, and the assumptions made when writing documents lead to situations where operations required changing multiple documents; or other corner cases that triggered loss in larger schemas. Of course, if you used MongoDB as intended, which was for ingesting lots of data with some tolerance of loss, you were totally fine.

2 ms·

I built something similar years ago. These are terribly hard to build, so I did a bit of digging. 1: This appears to be backed by a French company called Linag

by gwbas1c 1y ago

evolve2k 1y ago
I’ve had similar warnings from multiple very senior devs to never go near mongo. So better explain that choice if you’re wanting adoption. Reliability was the concern.
- gwbas1c 1y ago
  At the time (2010), MongoDB was intended (from the creators) for handling high volumes of data where some loss was tolerable. What happened was that its document model, and flexible index model, made it very attractive as an easy-to-use database. I used to call it the "Visual Basic" of databases. I think the less technical people in marketing latched on to how a lot of people found MongoDB easier to work with, and there was a lot of selling to people who it shouldn't have been sold to. The problem was that the lossiness nature of MongoDB didn't rear it's ugly head until deep in a project, and the assumptions made when writing documents lead to situations where operations required changing multiple documents; or other corner cases that triggered loss in larger schemas. Of course, if you used MongoDB as intended, which was for ingesting lots of data with some tolerance of loss, you were totally fine.