What do you think?
The mongodb hype seems to have died down overall. These days there seems to be more better (arguably), cheaper, easier alternatives coming up, usually offered by cloud providers.
would you rather use mongodb for a new project or any of the newer dynamodb, cockroach db, cosmos e.t.c databases ?

This cockroachDB always cracks me up.

Wonder who came up with that name.

Depends on what you want to do?.

For example mongo has more data support for a Nosql database where as dynamo doesn't.. even uploads are limited

namikaze:
What do you think?
The mongodb hype seems to have died down overall. These days there seems to be more better (arguably), cheaper, easier alternatives coming up, usually offered by cloud providers.
would you rather use mongodb for a new project or any of the newer dynamodb, cockroach db, cosmos e.t.c databases ?

Relational databases are time tested and are actually the more practical option in many instances. Imagine the headache involved in deploying a banking app with mongodb.

I choose distributed relational databases for most of my deploys now due to their resilience. They are set up and forget systems with automated back ups and guaranteed resilience.

Mongodb is still a great choice for projects with many sub data types like articles and comments. Mongodb would work well with a site like Nairaland for example if Seun plans on upgrading the comments to allow upvotes and downvotes, like in Reddit.

GREATIGBOMAN:
This cockroachDB always cracks me up.

Wonder who came up with that name.

lol, like why cockroach, whats the meaning behind cockroach, and to think there are probably some paid "professionals" who came up with the name

post=119977775:
Depends on what you want to do?.

For example mongo has more data support for a Nosql database where as dynamo doesn't.. even uploads are limited

yeah it mostly depends,
aws for example provides documentdb with a very similar api to mongodb but is faster and much more cheaper.

truthCoder:


Relational databases are time tested and are actually the more practical option in many instances. Imagine the headache involved in deploying a banking app with mongodb.

I choose distributed relational databases for most of my deploys now due to their resilience. They are set up and forget systems with automated back ups and guaranteed resilience.

Mongodb is still a great choice for projects with many sub data types like articles and comments. Mongodb would work well with a site like Nairaland for example if Seun plans on upgrading the comments to allow upvotes and downvotes, like in Reddit.

valid argument, but what about something like documentdb provided by both aws and azure, they do the same thing as mongodb but are generally faster, cheaper and easier to setup?

namikaze:

valid argument, but what about something like documentdb provided by both aws and azure, they do the same thing as mongodb but are generally faster, cheaper and easier to setup?

Same as firestore.

Non relational databases have their own peculiarities and should only be deployed to projects that benefit immensely from such structures. I don’t quite get why i would deploy a mongo db instance only to now hack at it with mongoose.

I think firestore is the cheapest of their bunch but I might be wrong. I am more skewed towards psql.

I want to be able to ‘see’ the data in my head as i write the codes.

truthCoder:


Same as firestore.

Non relational databases have their own peculiarities and should only be deployed to projects that benefit immensely from such structures. I don’t quite get why i would deploy a mongo db instance only to now hack at it with mongoose.

I think firestore is the cheapest of their bunch but I might be wrong. I am more skewed towards psql.

I want to be able to ‘see’ the data in my head as i write the codes.

I agree, I mostly use postgres for my projects
sometimes though a nosql db might be better choice, say for logs, metrics or 1 dimensional entity, and for these, I think I'll ditch mongo for the newer nosql dbs provided by aws,gcp etc.

namikaze:

I agree, I mostly use postgres for my projects
sometimes though a nosql db might be better choice, say for logs, metrics or 1 dimensional entity, and for these, I think I'll ditch mongo for the newer nosql dbs provided by aws,gcp etc.

Give cockroach db a trial. Spool up a cluster and you would love it.

It uses gcp or aws and gives you a choice.

truthCoder:

Give cockroach db a trial. Spool up a cluster and you would love it.
It uses gcp or aws and gives you a choice.

Yeah sure, thanks for the heads up.

truthCoder:


Relational databases are time tested and are actually the more practical option in many instances. Imagine the headache involved in deploying a banking app with mongodb.
.

I like to learn a lot. Please can you mention one practical headache (with proof if possible and not hearsay) ?
Thanks

truthCoder:


don’t quite get why i would deploy a mongo db instance only to now hack at it with mongoose.

No offense boss, but i think we should take it easy with opinionated responses; as you could easily and mistakenly mislead somebody with what you think is true.
The above statement is akin to saying "don't quite get why i would deploy a javascript project only to now hack at it with React"
you get it now, don't you? Nobody is stopping you from writing a complete app with just html, css and js files. In fact, that's what web dev used to be, right? But at least, you don't need to be told what React does to that process.
Now substitute mongodb for js and mongoose for React; and you will get the bigger picture. In other words, nobody is forcing you to use mongoose. Heck, you could forge a complete app without it.
Most people often forget mongodb is the native driver. And working directly with drivers require skills. Do it if you that's your style or just use an abstraction and speed it up, if that's also your style.

QuoteJustOnce:


No offense boss, but i think we should take it easy with opinionated responses; as you could easily and mistakenly mislead somebody with what you think is true.
The above statement is akin to saying "don't quite get why i would deploy a javascript project only to now hack at it with React"
you get it now, don't you? Nobody is stopping you from writing a complete app with just html, css and js files. In fact, that's what web dev used to be, right? But at least, you don't need to be told what React does to that process.
Now substitute mongodb for js and mongoose for React; and you will get the bigger picture. In other words, nobody is forcing you to use mongoose. Heck, you could forge a complete app without it.
Most people often forget mongodb is the native driver. And working directly with drivers require skills. Do it if you that's your style or just use an abstraction and speed it up, if that's also your style.

I understand where you're coming from. You're right that it's important to be careful with opinionated responses, as they can be misleading. My apologies if my previous response gave that impression. However, the thread was about personal opinions about MongoDB and not the academic definition of its concepts.

In regards to the comparison made between React and Mongoose, I see your point. React is a library that can be used to build JavaScript projects, and Mongoose is a library that can be used to work with MongoDB. Both can be used to make the development process more efficient and streamlined, but they are not required.

MongoDB and SQL are two different types of databases that serve different purposes. MongoDB is a NoSQL database that is great for storing and retrieving large amounts of unstructured data, while SQL is a relational database that is good for managing structured data.

One major difference between the two is that MongoDB doesn't have a predefined schema, which means you don't have to structure your data in a specific way. SQL databases, on the other hand, have a predefined schema and require data to be structured in a certain way.

People use Mongoose with MongoDB so as to define and enforce schemas at the application level, a feature which is not available at the database level with MongoDB.

However, Mongoose isn't necessary for every project and may not be the best choice. If a project requires a lot of relational mapping among fields on different tables, an SQL database may be a better choice. Using MongoDB with Mongoose in this case could be overkill and would require extra effort to enforce relations at the application level.

If you have a project that requires structured data at the database level, why would you want to use MongoDB and then Mongoose? This is what i meant in my previous post. From my little experience, a lot of people who do this are usually the MEAN and MERN stackers (Na beg i dey beg o, i no want any clapback) who don't have experience with distributed SQL instances.

Would a well funded team with a smart CTO deploy NoSQL when what they need is SQL?

QuoteJustOnce:


I like to learn a lot. Please can you mention one practical headache (with proof if possible and not hearsay) ?
Thanks

I know you just they whine me with the 'learn a lot opener'.

One big issue is that MongoDB doesn't have transactional consistency like SQL does. It makes it hard to ensure that all financial transactions are correct and the data is consistent.

Another issue is that MongoDB isn't great for complex queries and joins, which are commonly used in banking apps. It means that the development process would take more time and resources and the computational costs necessary to pull this is practically inefficient, relatively.

It also doesn't have support for foreign key constraints, which makes it hard to ensure that the data is correct and consistent. This is super important for banking apps where data integrity is crucial.

SQL has been proven in many financial applications and would be 50 years old next year.

Insightful thread.

I know React satisfactorily. Currently learning Nodejs, Express, MongoDB. Lemme learn the MERN stack well first then pivot elsewhere if need be.

Lol, a tool is only as power as its user. Just know what's best for the project and select the right tool.
I actually find MongoDB fascinating. You can make whatever you want with it. So far you know Data types, data structure and modeling and queries, you are good.

I just came here to say postgres is bae!!!

Anything I do these days is with postgres and get why.

Document databases are cool, but still give me postgres.