What you do mean by the "mongoDB trap"?
Are you saying companies are hurt by the license, or are you saying companies are hurt by software's behavior (e.g. consistency model)?
Are you saying companies are hurt by the license, or are you saying companies are hurt by software's behavior (e.g. consistency model)?
Then their sales people started coming around and asking for insane sums of money (like $10,000 per instance per year plus 100% markup on hardware to run in AWS - support is extra). They were worried about amazon and others offering a better so next they changed the license.
If it had been SQL it would have been easy to drop in another database. But Mongodb is so different from anything else that you need a major rewrite to get away from it. Postgres has some similiar functionality but it’s not drop in. Amazon has a more or less public beta of DocumentDB which as far as I can tell is a mongodb compatible interface to aurora backend - it works but doesn’t have the polish of RDS yet.
Well actually....
One corner case. If you are using Mongo with the Mongo Linq driver in C#, you can switch it out for an RDMS without changing too much code with just a little foresight.
Why use a relational store? If you’re working with a system that will only be read and written by an object based language? Why keep converting back and forth between a relational model and an object oriented model?
In C#
var seniorMales = from c in context.Customers
where c.Age > 65 && c.Sex == “M”
You get autocomplete and compile time checks.
When you want to add an record to your Mongo collection, you work with strongly typed
IMongoCollection<Customer>
Anything that you can store in object database you can normalize and store in an RDMS. ORMs have been translating relational models back and forth to object models for decades.
In the case of Mongo, you just create one object containing other objects, lists, arrays etc and the driver serializes it to a JSON like structure and stores it as is in the collection.
In the case of an RDMS, you create your C# classes to model your tables and relationships.
The driver translates the LINQ to the appropriate query language.
Well I can't tell you what the right choice in your system is, but in the general case I think going with a relational model by default generally makes sense because it's rather future proof. By that I mean a relational model gives you the most flexibility in the future to evolve your system in ways you couldn't/didn't anticipate when the system was initially designed.
No point using a relational db for that kind of thing.
Not to mention the LINQ driver....
And you can’t do updates on individual JSON fields in Postgres.
The problematic part with PostgresSQL JSONB is modifying a JSONB column content. In any case, we totally replace the old content by a new one. So, the update operations turn to the complex queries that can lose the content. You can avoid this by performing the full JSON reorganization before the persistent operation.
You still don’t have the richness of MongoQuery and the aggregation framework and the tooling around working with JSON data isn’t there. Let alone the native driver support.
When I did implement a system with C#/Mongo, I fell in love with changing my database schema just by changing my C# objects. With the C# driver you can include a Dictionary as part of your object to round trip unmapped fields.
Not to mention that after you go through all of your modeling and figuring out your aggregate roots, you can just store the entire object graph with one .Add and the entire object is stored atomically without having to worry about transactions, table locks, etc.
Unlike with an RDMS where your beautiful aggregate root has to constantly be composed and decomposed.
I think it’s just going to take somebody shaking the cobwebs off of their X.500 manuals and making the query syntax and schemas a little more ergonomic for them to come back en vogue.
It’s one thing to have the ability to mold your DB to model hierarchical data but have your DB engine support it non-awkwardly might be a game changer. People are already used to apps needing a DB, cache, queues, S3, filesystem, service discovery, that adding one more thing would hardly break the bank.
If the companies got lured into using MongoDB as a service, then I understand that prices could increase and companies could be in a pickle. But if companies got lured into using MongoDB as software, I don't see how they could have a problem.
The parent comment states "their sales people started coming around and asking for insane sums of money" but I can't find any reference to this.
If MongoDB really is sending salespeople to make claims against companies who they convinced to use their OSS database as a data-store, than they are indeed abusing their license and no one should use their database or support their company.
From what I read of the license, that shouldn't be the case though.
The only major change to the license is in adapting to the rise of cloud services.
That's one of GPL's biggest strengths.
Also successful software packages that are GPL are GPL for everyone. You don't have a mother company that can bypass the GPL due to them owning the copyright. And when you do it's usually a scam that people can smell.
You can't say about a license change that it is in the "spirit of GPL" when the mother company, MongoDB Inc, doesn't have to play by the same rules as everyone else.
So I'm sorry, but when you're talking about the "spirit of GPL", you don't know what you're talking about.
The FAQ for the license change very clearly indicates that your reading is what was intended. Question #4 particularly contains the complete text of the section that was altered, and it's hard to see how they could have left themselves any room to penalize regular users.
> If it had been SQL it would have been easy to drop in another database.
More likely, though, is that Oracle users use Oracle-specific flavors of SQL in lots of legacy apps that no one wants to touch, and rely on the support contracts for continued assistance in keeping the database performant for its query load.
There’s no incentive to not extend or try to improve SQL semantics because for proprietary databases it increases lock-in which is good for sales and for OSS databases the extensions are genuinely positive and increase developer productivity and you don’t feel bad about locking your users in because it’s OSS.
We tried to do a migration from Sql Server to Postgres.
Even went as far as building a parser/compiler to transform Sql. Certain things are just too difficult to handle.
1. Sql Server supports arbitrary sql statements in queries. Postgres does not.
2. Data types are not the same.
3. Feature sets at the 'interface edge' between the client library and the engine differ. For example, Sql Server queries can return an arbitrary number of results.
It's true that Mongo uses a custom language, but with Mongo - you are unlikely to have any significant business logic in your data layer.
Also their API surface is relatively simple.
For example, FoundationDB has a layer that mimics the Mongo API. Amazon has one as well.
To really take advantage of a database engine, you will probably end up using engine-specific idioms.
Postgres and Sql Server support recursive CTEs. MySql probably doesn't?
Sql Server supports cursors but is dog slow and generally not recommended for any sort of large scale operations.
Isolation levels and locking are really important as well. Do all engines even support the same isolation levels?
CouchDB is quietly weeping in a corner.
Hahaha. No.
If anything, migrating from something like Mongo might possibly be easier. Because it's non-relational, you probably have very little business logic in your database layer.
Unlike with Sql.
And even though Sql has a standard syntax, beyond vanilla CRUD queries, there are many differences. Even if 2 engines support the same synatx, the idiomatic way of doing something will differ.
(For example, cursors in Sql Server is extremely slow, whereas its a perfectly acceptable way of doing list operations in Postgres)
Additionally I'm curious how the license is harming companies, as I mentioned in this comment: https://news.ycombinator.com/item?id=20862996
MongoDB had a good run, I enjoyed it before migrating away. This license definitely hurts companies.
What to? I built my own Open Source solution (MIT/Zlib/Apache2).
Around same time Firebase was getting popular, and Graph databases were the way forward.
Combined them all together, now have Internet Archive and HackerNoon running it (https://github.com/amark/gun) in production!
Link to tech talk for others: https://www.youtube.com/watch?v=BEqH-oZ4UXI
Could you elaborate on how companies are hurt by the license?