Is MongoDB Atlas killing my company?
In a recent video about hosting solutions, Theo reluctantly added Atlas as an option for database hosting.
Saying: "Guys, I'm looking for hosting solutions, not ways to kill your company"
Now as someone who has a company and uses Atlas I'm rather curious where the resentment is coming from.
Why would you recommend against using Atlas (or MongoDB in general)?
77 Replies
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
because I'd bet a lot of money, that your data is relational... and there are just better options for relational data, e.g. relational databases
Just a basic example, how do you do migrations with MongoDB? It's really not that trivial, there is some community tooling around it, but not very good to be honest. And you WILL need to change your database schema as you explore the problem space.
Then just in general the company, the documentation and just plain everyhting about it feels so second tier, I hate it with a passion. Plus I know a guy that MongoDB hired, and if they hire guys like that, jesus christ it's a mess over there (said guy wasn't very good)
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I'm not gonna name him, but there's a developer I used to work with, who is just... not a good developer, and he was hired by MongoDB the company
I know, it's personal and in a way petty, but it was a really strong indication for me not to use their products
okay, now I feel bad, maybe he improved a lot and MogoDB is a good company
@j0hannes Hey, I see the German flag, are you in that region? I've been working with German / Austrian companies for the past 2-3 years and noticed that MongoDB is really popular in the region.
When I made the decision to use Mongo, I haven't had much experience with DBs at at all.
I just wanted to keep things simple and liked the idea of having JSON documents.
I mapped out out all the data I need on the frontend in a document I called Software Design Diagram. And I found out that I don't have that many connections. between the objects(documents) that my components need and that represent different aspects of my app.
So I didn't see the downside of having to query too much data at once, when I want sth more granular.
And I appreciated the fact that there is a company behind it that both improves on the ecosystem that they've built and is available to help me, should I need it. (as opposed to relying on getting help on some forum for an open source technology)
yes, I'm not sure how popular Mongo actually is, but I've just been to MongoDB.local Frankfurt this week
there were about 200 people maybe (hard to guess). Great event.
So the issues you will probably run into, well I have and the companies have that I've seen, is not really performance related.
They never really got to that scale, think 1-10k user base, niche specific business
BUT! There were just so many bugs... Maintaining it well, and moving fast with it, to me just seems much harder than with a more traditional, tried and tested relational database.
It's fine if you just need something to throw stuff into
But once you start having relationships between the data, and try and solve that in Mongo, it gets really messy
I have a shit-ton of data, but few connections
And I'm also looking in the future for when I'm using more external tools, such as analytics software which will create their own events and attributes. I think with Atlas services and with data federation I can simplify getting that data back into my app. At least I hope that's the case.
I like that they sell themselves (Atlas) as an all in one solution to handle data. Because things can get quite complicated when you have multiple tools, (reverse) ETL's, a warehouse, etc.
I guess the key would be the "I have a shit-ton of data, but few connections" part
Hey, if it works for you, there's a local community with cool people, fits your use case, you can develop your features fast enough and it makes you enough revenue 🤷♂️ Who am I to tell you you're doing something wrong 🙂
Here's MongoDB's official comparison article
https://www.mongodb.com/compare/relational-vs-non-relational-databases
MongoDB
Relational Vs. Non-Relational Databases | MongoDB
Learn about different types of databases and things to consider when choosing what database technology to use in your project.
I'd argue that the points they bring up as negative for relational DB-s is just not true.
Interesting - Maybe you can elaborate on scalability and flexibility?
I liked the idea of having flexibility with Mongo. From the standpoint of making mistakes (that I anticipate making) more forgivable.
Although I have clearly defined schemas.
I guess you would argue that one is actually less flexible with Mongo?
Different point:
this could be considered a disadvantage of ralational dbs - although I'd better term it a side effect that can be circumvented:
Many people - when thinking about the data of the application they plan to make - start out by thinking of their data in terms of how they would structure their relational db. Maybe they whip out some diagramming tool and start defining tables.
I am very glad I didn't do that.
Rather I thought about my app in terms of objects that I need on the front end.
And which of the fields on those object need to be persisted and why.
The result is that I had an easier time thinking about how to structure my app.
And the db closely resembled what I need on the front end and someone else can easily look at the diagram I created in Figma and understand it.
The shape of your data, your schema, is going to change
I bet
So having a solution for that is probably the most important
MongoDB just doesn't have that
They advocate for you to solve it with document versioning, etc.
Which I think is just not a good idea
The existing community driven frameworks around it are not the best, as far as I know
So e.g. Django from the python world has an mature tool for migrating your data and schema
OK, that's the framework, but at least there's a good way of doing it
I haven't really seen anything for MongoDB in any framework that I know of... only hobby projects in C# and node and maybe python and javascript
So for me, this is reason enough to not use Mongo
The other thing is, I'm almost 99% sure your data is relational.
Like if you have users, and other stuff... you probably have relationships between users and that other stuff...
Okay maybe you can maintain it for 2 entites, but what if you have 3, 4, 5...
That's reason 2 why I just wouldn't use MongoDB
But, of course, it's possible your data is in fact not relational, then MongoDB is fine I guss
hi, we use mongo to manage data that is known to be too chaotic to manage in a typical sql database, however we always add a layer to communicate with it to normalize the insanity. so direct communication with the mongo instance is pretty restrictive.
[in my company]
as an example to this is a menu system in a delivery company
different menu items require different types of categorization [food, clothes ,etc] , thus creating a sql database for it would result in an extremely complicated migration strategy
also integration with outside POS systems dictates that you must obey the way they structure things , thus making the concept of the database as the source of truth moot
so if i would use a mongo db, i'd use it when i have lots of integrations with outside systems that i cant manage/control
just my 2 cents <:rcon_peeposhrug:794991757771145216>
That's true, if you have a bunch of different type of data, that you can't control and need something to throw everything into, MongoDB can do that
It's nice that it has pretty good text search built in for example, and you don't ahve to pull up an elastic search or solr separately to handle that
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Mongo definitely has its use cases...like what... 🙈 no seriously, I hate mongoDB so much... when is it actually useful?
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
that's like "soundcloud is ruby on rails and instagram is python django"... everything works if you throw 100+ really good devs and 100M+ USD on it...
sure, on a small scale, everything works
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
exactly
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
did you notice that MongoDB is branding itself similarly to codecademy???
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
check out their website
and check out codecademy's
there are some very similar design ques
cues? Englishing is hard
design tokens
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
or, it's a conspiracy.... they try to funnel in poor devs who just finished codecademy
and once they get them, they never let them go
because they never learn relational databases, so they can never leave!
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
exactly!
see what I mean?
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
yeah that seems pretty cool
have you played with it?
I've only seen some youtube stuff
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
oh, dayum!
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
work?
fun?
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I'll check it out for sure!
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Hey, OP, actually look into this! @j0hannes this is a really good tip
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
GitHub
Support EdgeDB · Issue #10210 · prisma/prisma
Problem EdgeDB is a database built on top of PostgreSQL. https://www.edgedb.com/ EdgeDB is a next-generation database that gives developers superpowers. It takes the tools and features you know and...
omg what if I hate it?
and want to switch to another database
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
okay...
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
okay, sold, I'm doing my next side project with EdgeDB
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
why is that awkward...?
defining some sort of schema seems fine to me
how could the query builder build the queries without a schema?
or whay am I missing?
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
IDK, I never used mongo, but recently I was trying to fit tech for my side project - needed scale to 0 DB (either SQL or NoSQL). For SQL there not so many options. Planetscale is nice, but payment aspect is not totally scale to 0. So NoSQL seemed like a choice. Since mongo works with prisma, I thought it can be a good idea to start with mongo on atlas, but at some point switch to SQL DB (I assume prisma helps) or DynamoDB depending on product development dynamics. Is there anything I got wrong?
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Migrating data is not fun in general ^)
But prisma layer should make it easier, should't it?
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I mean I'm just curious what is wrong with mongo
Cause I read the thread and got nothing useful on that matter
Just how you guys hate mongo 🙂
Maybe missed something...
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
Well, that doesn't seem like mongo's problem ))
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I think yall are being too hard on Mongo.
Before I started using it I actually tried to make sure, that I'm not another js dev who does it because it looks easier than a relational db.
I know what I need to GET from my db. I've made collections for those things.
Those collections are connected, but it's very simple. A user has a bunch of hubs, which have a bunch of secions, which have a bunch of sources. And there are a truck load of items (referenced by sections and by sources).
If I can get a faster read throughput of my items then I'm happy.
Mongo is all about asking yourself:
What queries do I need. And then making sure that "things" that are queried together are stored together.
If you have more "things" at the same time... then you need more joins and you're probably better off having chosen a relational database.
For now I'm happy that my system is simple and performant.
And then making sure that "things" that are queried together are stored together.That's the part that usually fails, or sucks ass to maintain if it doesn't... That's me, yes I think Mongo is 2nd tier software at best if not completely trashware. If you need simplicity to get started, there are simpler options out there, both noSQL and SQL options. If you need true performance (which you don't, none of us work at, youtube, facebook or anything remotely at scale), then again obviously there are better options both NoSQL and SQL. Mongo is like the appendix, it's like an evolutionary cul de sac... Back in the day, a long long time ago it was the simplest solution when you just wanted to put sht into something. Also it was considered "cool" because NoSQL was going to take over the world. Well, it didn't... It's like a phase you go through, when you're a teenager and listen to shit music and embarassingly think it's good, because you just don't know better yet. And the reason I absolutely do hate MongoDB, is being the false prophet it is, "oh no, you don't need relations, just keep track of relationships by duplicating on the different documents and you know, document versioning and stuff" No, no, no and no!!!!! Did I say no? NOOOOOO It doesn't fcking work!!!! It never did, and never will. If you indeed need to optimize your requests, which you don't because you're not like... Alibaba or Amazon where there's actually a lot of data... and need to speed up lookups by flattening the data into documents, well by all means, sure, use Mongo... oh no wait, what's this? Cassandra...? Oh you need text.... hello Elastic Search!!! Wow new versions of Solr is pretty cool and damn it's battle tested as hell... And in that case, you're probably better off having AN SQL DATABASE and just seeding another layer for the super fast stuff... and then you might want to use something in memory anyways... So no, you should not use MongoDB
surrealdb are planning to add an sql migration adapter
basically you can move data in and out of surreal db with sql
if they manage to make it be compatible with sql then its probably going to be really good
the fundamental problem here is the illusion of scalability, if you understand your project well enough that you can pre plan the data diagram, then obviously nosql seem rather pointless, but for alot of people they tend to just "free roll it" and to them , less restrictions "sql is a form of restriction " means more work done
its similar but no where near the debate around rust lang for example , why code something in any language if rust exists
also, data mapping is hard, there is a reason why we hire DBAs etc, its a whole different layer of development .
and when your developing apps, your developing apps, database concerns should be minimal at the start , but insanely huge later on , and thats where the nosql catch is
i think there is a healthy route for apps to start off w no sql then transition to sql, but it requires some level of foresight
Good take
Mongo can be useful if you really know what you're doing with it
But if you're asking "Should I use SQL or Mongo?", the answer is SQL
If you're saying "BUT MONGO PERFORMS REALLY WELL IN THESE 7 CASES THAT SQL IS BAD AT", cool you know more than me, go use Mongo
sure, I just hate MongoDB, felt good to let it all out
this is actually really banger, i've been using Atlas at synapse for some time now, and for things that don't really need to scale well it's great. we're looking to migrate soonish and all of my devs know Mongo really well so we've been looking to alternate solutions. They love the idea of pscale but it's going to be a learning curve for all of us. i've been thinking how much i'm going to need to have invested to move us all to something different (optimally pscale), any thoughts on the migration and investment of time/money to train and move all our shit?
Move to Prisma first
Then use Prisma to move to any sql you can
we've started moving to prisma. all our new stuff uses prisma by default and we're retroactively migrating older stuff. a small problem is that some of our shit uses Kotlin on either the JVM or native so those are gonna be our choke points
@Lizzy A Havent tried Prisma yet, but from the looks of it if I had setup my mongodb using prisma, then I could have migrated it to mysql without breaking a sweat?
Prisma is just generally great. It'd still require work to change BUT it'd be far less effort
Instagram for a long time was just that though with a lean team of tens of, if not less than ten, engineers, and definitely not $100MM of money to play with
but you don't substantiate good advice for the masses with outliers... they are the exceptions that prove the rule, not the data points you should extrapolate from
that's like saying leave college, because Bill Gates
if you have the amount of talent Instagram had, sure... it will work out... they probably could have and would have hacked it all together with vanilla JS and machine code if they had to
let's just agree that MongoDB is horrible, it makes me feel nice and fuzzy on the insides
I'm just responding to what I took your argument to mean that throwing money and eng resources at something will make any garbage work by saying that Instagram actually didn't run that way yet succeeded and scaled anyway. You're making a completely different point now
But I agree that there would have to be more than "discord used mongodb for a hot minute" to make a convincing case for it
now you're making me read back my old comments, jeeez, I'm just here to spread the word --> ditch Mongo
But I also don't think that was the point of that remark
My main point is... just don't use Mongo, unless you have to because legacy
But then, you should really be paid well
So this isn't about document databases altogether but just mongodb. What makes mongodb particularly bad, especially since I consider all of these to be bucketed the same but with some different tooling and integrations?
This was meant as a reply to your point about using Cassandra or elastic search but somehow replying didn't work
Let me get my coffee
Okay, so when do people generally use a NoSQL database?
A) When they beleive the promise that it will be simpler than SQL
B) NoSQL measurably performs better or can't do what needs to be done
*SQL can't do
I'd argue that B is incredibly rare
And when it is B) indeed, then still usually there are other better tools (this is where I brought up Elastic Search or Solr for text search and super fast read indexing / search in general)
I've never worked at a scale where the usual arguments about sharding, etc would matter, but if you read up on it, supposedly MongoDB doesn't scale well
*never worked at a scale with MongoDB
Okay so we don't pick Mongo when we have to do stuff at scale because let's believe the people who had to make these decisions
Not on scale Mongo is terrible, imho, because it has a bad DX, no good tool for migrations, and in general just everything about it is so... meh... the docs are bloated, convoluted, and at the same time somehow incredibly vague
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View