6 ms·

A lot of companies got lured into using mongodb because it was so developer friendly. It cost nothing and it was easy bring in the back door and alleviated the

A lot of companies got lured into using mongodb because it was so developer friendly. It cost nothing and it was easy bring in the back door and alleviated the need for thought. 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.

scarface74 7y ago
But Mongodb is so different from anything else that you need a major rewrite to get away from it. 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.
- 6nf 7y ago
  So why not just use a RDMS from day one?
  - scarface74 7y ago
    Because we had data that fit better in a non relational store. We stored data that created from user generated forms and we loaded data back into those forms. 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” Would be translated at runtime to either MongoQuery, Sql, a foreach loop, etc depending on what “context” represented. 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> And the compiler will ensure that your collection stays consistent.
    - 6nf 7y ago
      That doesn't make sense - how are you eventually moving to a RDBMS if your data is not suited to it?
      - scarface74 7y ago
        What do you mean how? 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.
    - liability 7y ago
      > 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? 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.
      - scarface74 7y ago
        If your data store is behind an API you modify the API. You’re often using a different database for your OLAP and OLTP anyway.
      - xchaotic 7y ago
        I think you got it backwards. A relational schema change is required and probably a data reindex or reload when you change a data model so relational is the least flexible as opposed to something like Mongo nosql?
  - zxcvbn4038 7y ago
    A lot of people have difficulty trying to organize complex hierarchical data into rows and columns. A lot of places make you go through a dba to create or change a database which rubs power users the wrong way - and admittedly most of the dbas I’ve worked with are a lot more concerned with making backups fast then in your applications performance. Mongodb doesn’t make you do any of that. It doesn’t make you have authentication either. I think that’s a big reason why it got so popular.
    - scarface74 7y ago
      Database versioning and migrations are a pain. I’ve tried both home grown and commercial database systems to make database changes part of the CI/CD process. I haven’t found one that I liked. 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.
    - Spivak 7y ago
      I think it’s funny that web devs pretty much abandoned hierarchical databases since they are the OG database style. 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.
- chrischen 7y ago
  Also Foundation DB supports mongodb clients. It also powers iMessage.
Thorrez 7y ago
Maybe I'm misunderstanding, but I thought the new license is just about offering MongoDB as a service by itself. But if you're making any other sort of website and use MongoDB as a database, you can still install it and use it for free. 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.
- judge2020 7y ago
  You're correct, the new license only prevents AWS and other cloud from running the MongoDB software itself as a managed service unless they open-source their entire platform (although, as we see with DocumentDB, they can legally implement the API without the license coming into effect). 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.
  - CryoLogic 7y ago
    This was my understanding of the license as well. I read through the block and it very clearly suggested only selling the database as a service was not okay. Using the database as a data store should be fine. 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.
- tedivm 7y ago
  The fact that mongo was willing to screw over one set of users makes me worry they'd be willing to screw over all their users. It's a risk I wouldn't take, especially when there are so many other (arguably better) options out there.
  - lolinder 7y ago
    I wouldn't choose mongo for many reasons, but this licensing change isn't one of them. It's in line with the general spirit of the GPL: if you're going to stand on the shoulders of giants, you should allow others to stand on your shoulders. The only major change to the license is in adapting to the rise of cloud services.
geowwy 7y ago
> If it had been SQL it would have been easy to drop in another database. Not true at all. Way too many organisations are locked into Oracle just because it's too hard to switch to something cheaper.
- willio58 7y ago
  Why is this? If Oracle uses SQL why can you not just export the database, make some transformations, and import it into a PostgreSQL db for example?
  - peteretep 7y ago
    Because Oracle uses Oracle's flavour of SQL, and no two databases are feature compatible.
  - lsb 7y ago
    If you are correct then your consultancy can stand to make hundreds of millions and save companies billions on their Oracle instances! 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.
  - deleted 7y ago
    [deleted]
  - Spivak 7y ago
    I feel like you’re imagining that SQL is more of a standard interface than it actually is. No two relational databases are quite the same and you’ll be stuck combing through your entire app looking for obscure syntax usage that depends on Oracle specific extensions or quirks. 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.
    - 7y ago
mr_toad 7y ago
> Mongodb is so different from anything else CouchDB is quietly weeping in a corner.
statictype 7y ago
>If it had been SQL it would have been easy to drop in another database. 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)

scarface74 7y ago

But Mongodb is so different from anything else that you need a major rewrite to get away from it. 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.

6nf 7y ago
So why not just use a RDMS from day one?
- scarface74 7y ago
  Because we had data that fit better in a non relational store. We stored data that created from user generated forms and we loaded data back into those forms. 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” Would be translated at runtime to either MongoQuery, Sql, a foreach loop, etc depending on what “context” represented. 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> And the compiler will ensure that your collection stays consistent.
  - 6nf 7y ago
    That doesn't make sense - how are you eventually moving to a RDBMS if your data is not suited to it?
    - scarface74 7y ago
      What do you mean how? 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.
  - liability 7y ago
    > 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? 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.
    - scarface74 7y ago
      If your data store is behind an API you modify the API. You’re often using a different database for your OLAP and OLTP anyway.
    - xchaotic 7y ago
      I think you got it backwards. A relational schema change is required and probably a data reindex or reload when you change a data model so relational is the least flexible as opposed to something like Mongo nosql?
- zxcvbn4038 7y ago
  A lot of people have difficulty trying to organize complex hierarchical data into rows and columns. A lot of places make you go through a dba to create or change a database which rubs power users the wrong way - and admittedly most of the dbas I’ve worked with are a lot more concerned with making backups fast then in your applications performance. Mongodb doesn’t make you do any of that. It doesn’t make you have authentication either. I think that’s a big reason why it got so popular.
  - scarface74 7y ago
    Database versioning and migrations are a pain. I’ve tried both home grown and commercial database systems to make database changes part of the CI/CD process. I haven’t found one that I liked. 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.
  - Spivak 7y ago
    I think it’s funny that web devs pretty much abandoned hierarchical databases since they are the OG database style. 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.
chrischen 7y ago
Also Foundation DB supports mongodb clients. It also powers iMessage.

Thorrez 7y ago

Maybe I'm misunderstanding, but I thought the new license is just about offering MongoDB as a service by itself. But if you're making any other sort of website and use MongoDB as a database, you can still install it and use it for free. 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.

judge2020 7y ago
You're correct, the new license only prevents AWS and other cloud from running the MongoDB software itself as a managed service unless they open-source their entire platform (although, as we see with DocumentDB, they can legally implement the API without the license coming into effect). 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.
- CryoLogic 7y ago
  This was my understanding of the license as well. I read through the block and it very clearly suggested only selling the database as a service was not okay. Using the database as a data store should be fine. 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.
tedivm 7y ago
The fact that mongo was willing to screw over one set of users makes me worry they'd be willing to screw over all their users. It's a risk I wouldn't take, especially when there are so many other (arguably better) options out there.
- lolinder 7y ago
  I wouldn't choose mongo for many reasons, but this licensing change isn't one of them. It's in line with the general spirit of the GPL: if you're going to stand on the shoulders of giants, you should allow others to stand on your shoulders. The only major change to the license is in adapting to the rise of cloud services.

geowwy 7y ago

> If it had been SQL it would have been easy to drop in another database. Not true at all. Way too many organisations are locked into Oracle just because it's too hard to switch to something cheaper.

willio58 7y ago
Why is this? If Oracle uses SQL why can you not just export the database, make some transformations, and import it into a PostgreSQL db for example?
- peteretep 7y ago
  Because Oracle uses Oracle's flavour of SQL, and no two databases are feature compatible.
- lsb 7y ago
  If you are correct then your consultancy can stand to make hundreds of millions and save companies billions on their Oracle instances! 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.
- deleted 7y ago
  [deleted]
- Spivak 7y ago
  I feel like you’re imagining that SQL is more of a standard interface than it actually is. No two relational databases are quite the same and you’ll be stuck combing through your entire app looking for obscure syntax usage that depends on Oracle specific extensions or quirks. 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.
  - 7y ago

mr_toad 7y ago

> Mongodb is so different from anything else CouchDB is quietly weeping in a corner.

statictype 7y ago

>If it had been SQL it would have been easy to drop in another database. 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)