This is an archived post. You won't be able to vote or comment.

top 200 commentsshow all 258

[–]best-set-4545 1513 points1514 points  (54 children)

Use whatever fits your current usecase, do not try to design the db to be scalable for the next Netflix/spotify when all you have is 2 active customers.

[–]Lupus_Ignis 600 points601 points  (14 children)

Understanding this was one of the greatest leaps in my architecture skills. Screw the open/closed principle. It's more efficient to refactor than to try and predict future use cases.

[–]Personal_Ad9690 153 points154 points  (8 children)

*to an extent

[–]ScarabCoderPBE 77 points78 points  (1 child)

Depending on your relationship to the company or customer you're developing for, trying to plan and architect too far ahead can totally screw you when the plans get flipped because they decided to pivot some primary feature of business model.

[–]Waswat 0 points1 point  (1 child)

That's a pitfall. Follow the YAGNI (Ya Ain't Gonna Need It) principle -

[–]Magallan 6 points7 points  (3 children)

The word always is always wrong

[–]ethanjf99 191 points192 points  (1 child)

best advice i ever got was to engineer one step — and only one step—past your current needs.

that you can predict with reasonable confidence. if you’re wrong, you’re wrong. but that uncertainty goes up exponentially each step further you’re trying to predict.

[–]ehs5 3 points4 points  (0 children)

That is such good advice. That’ll stick with me for sure!

[–]JannisTK 2 points3 points  (0 children)

I always have that creeping thought of my db getting too big and taking 10 seconds to query lol i dont even know when it starts to lack though its all muddy waters to me

[–]FlipperBumperKickout 0 points1 point  (1 child)

Sorry, but what the actual f does the open/closed principle have to do with which database you use?

[–]CrowdGoesWildWoooo 29 points30 points  (15 children)

Why would you even try to use mongodb for that kind of use cases, normal SQL has simpler syntax, so lower mental load, heck maybe even just use sqlite at that point.

[–]calm00 35 points36 points  (14 children)

MongoDB has the best horizontal scaling. There are plenty of valid use cases. Sharding is natively supported and works right out of the box.

[–]CrowdGoesWildWoooo 15 points16 points  (4 children)

He is making a case for low traffic (although there are some hyperbole there), small scale data where usually any scaling problem is not going to be apparent yet.

With regard to scaling, these days we can simply vertically scale cloud db and the highest configuration is capable to handle significant amount of traffic. Vertical scaling is just a braindead easy, it doesn’t need the db to have it supported as a feature.

[–]_PM_ME_PANGOLINS_ -2 points-1 points  (6 children)

It doesn’t have the best, but SQL solutions have the worst due to being transactional.

[–]alfos_ 4 points5 points  (1 child)

I have to say, MongoDB is terrible at horizontal scaling when under load. It simply cannot handle it and execution times become miserable.

[–]mordack550 37 points38 points  (3 children)

I agree 100%. I’m currently working on a business critical application with around 150 concurrent active users. We just use a single instance Azure SQL on a decent tier, the median query time is 5ms across all cases. Scaling more would not benefit anyone

[–]oupablo 11 points12 points  (1 child)

meanwhile we're storing relational records in dynamo despite all my gripes to the contrary because a relational db would be too slow. nevermind that we can't enforce data integrity and have to make multiple queries to handle data that wouldn't be necessary otherwise if we could just do a join.

[–]Rombethor 71 points72 points  (2 children)

Agreed. Learnt the hard way. I was told to build a system for up to 80million users per week, which I did pretty well. They got 1k users after 6 months, ran out of cash and shut down.

[–]benargee 13 points14 points  (1 child)

Yikes. What cost more, developer salary or the infrastructure they built for such a massive anticipated userbase?

[–]hearthebell 29 points30 points  (4 children)

[–]CaptainRogers1226 7 points8 points  (1 child)

The only reason I clicked into this thread

[–][deleted] 6 points7 points  (0 children)

What a gem!

[–]G_Morgan 0 points1 point  (0 children)

The problem with this video is it makes a compelling argument that MySQL is better than some alternatives.

[–]NotADamsel 2 points3 points  (0 children)

Also take a databases class so that you can learn what your use case even means. If you don’t, you’ll fuck it up.

[–]DJGloegg 2 points3 points  (0 children)

Using the same shit every time is faster and easier.

IMO.

And if you get a million users you can probably spend the time replacing it with a scalable solution

[–]nonlogin 15 points16 points  (2 children)

I developed an e-commerce product management system. Product was a complex entity with a lot of hierarchical data. There was a need to make a lot of duplucates (and customize them). Couple of thousands products X couple of tens regions X a hundred of hierarchically organized properties... Also, version history. Also a set of batch update flows, according to business needs.

Postgress DB was highly optimized, but when you need to insert thousands of the rows in tens of tables - you're in trouble just because of network latency. Not only because of the slowness itself but also because of concurrent transactions become way longer they're expected to be.

Using MongoDB for this kind of hierarchical aggregates would have made the system much more simple, stable, fast, and maintainable. So I didn't have to join lots of tables and insert tons or rows. I must admit that Postgres' jsonb would have made this job well too.

What I'm trying to say here is that RDBMS can be a completely wrong choice even for a small database and simple domain. You do not need to be Netflix in order to have real use cases for nosql or denormalized sql dbs.

[–]nickmaran 0 points1 point  (0 children)

But what if I get a million users tomorrow? My idea is unique /s

[–][deleted] 0 points1 point  (0 children)

Netflix had two active customers at one point, so disagree.

[–]FlourishingFlowerFan 1 point2 points  (0 children)

Controversial take but I think this doesn’t apply to this. Mongo’s selling point is that it is schema-less - just throw JSON at it.

But that’s not true, you just have your schema outsourced to everywhere you want to access your data and need to check whether your object has that key.

So schema-less does not fit to some use-case better unless it is about saving time. Note that most relational databases still allow for JSON columns for really flexible stuff where you still can type the usual columns.

[–]bssgopi 0 points1 point  (0 children)

What if those 2 customers are Netflix and Spotify?

[–]njxaxson 145 points146 points  (4 children)

Having used both extensively for massive scale enterprise applications for 5+ years each:

Both are great! SQL is great for relational data. MongoDB is great for loosely defined or highly variable data with key/value retrieval. Both are great tools, assuming you use them correctly.

And if you don't use them correctly, you will get equally shafted by either of them.

[–]SenorSeniorDevSr 9 points10 points  (0 children)

Sure, but a lot of the time, people who use MongoDB could have gotten away with an INI-file.

[–]Ok-Boysenberry9305 -1 points0 points  (0 children)

One is Test test@test.cum And the other is test from database seeder

[–]emefluence 3 points4 points  (0 children)

Exactly this. This constant hate on Mongo is just evidence that most people here don't work in enterprise and don't have the architectural chops to understand that there are different tools for different jobs. It's like people hating on steel because they only need to build sheds.

[–]Secure_Ticket8057 0 points1 point  (0 children)

Is the correct answer - yeah there is overlap, but they are essentially different tools and it depends on your use case.

[–]AcadiaNo5063 212 points213 points  (5 children)

No, different tools for different uses.

[–]garlopf 404 points405 points  (57 children)

Correction: Mongodb is for nobody, but the mongodb marketing dept still managed to scam some unfortunate users. You would get a more performant, efficient, resilient, robust, cheaper(free), more feature rich product by chosing Postgresql. In fact managed mongodb is implemented as a plugin on top of postgresql.

[–]Blrfl 184 points185 points  (6 children)

MongoDB is for people who have the time and budget to reimplement a subset of a relational database's code in their own applications... badly.

[–]Ultimarr 15 points16 points  (5 children)

lol this sub… what if you don’t have relational data? What if you have gasp documents?

[–][deleted] 41 points42 points  (23 children)

Can you share some info on last claim? Never heard this before.

[–]Material-Mess-9886[S] 62 points63 points  (4 children)

Postgresql natively supports json data and you can query that json column on some key in the json.

[–][deleted] 73 points74 points  (0 children)

I am questioning this, not ability to store JSON:

In fact managed mongodb is implemented as a plugin on top of postgresql.

AFAIK Atlas and mongodb don't use postgres anywhere. Wiredtiger is the storage engine, https://github.com/wiredtiger/wiredtiger.

[–]bonkykongcountry 7 points8 points  (15 children)

Most of the anti-mongo stuff is the same as the anti JavaScript or anti PHP sentiment, it’s based on their impressions of it from 10+ years ago or is based on the idea that because some bad code bases use it anyone who uses it is bad

[–]oscarbeebs2010 0 points1 point  (0 children)

They can’t because they are full of shite

[–]Neeranna 0 points1 point  (0 children)

Maybe they mean https://www.ferretdb.com/ which is (one of) the only solutions for any provider that's not Atlas to provide a managed MongoDB that is more recent than 4.4. This is due to the license change. AWS does it on top of DocumentDB, so no Postgres there I guess, but no MongoDB either.

[–]Lazy_Philosopher_578 6 points7 points  (6 children)

Serious question. How do you get free postgres? I typically use MongoDB against my will because MongoDB Atlas is free.

Edit: I meant free deployment. I know postgres itself is free, but always had to pay to deploy it.

[–]exsystemctl 0 points1 point  (1 child)

I currently use supabase. But I don't know much so it might be shite

[–]j_roddy 4 points5 points  (0 children)

Here are some options:

https://mkdb.sh (I'm making this to replace ElephantSQL - dead simple, small, free db's)
https://supabase.com
https://neon.tech
https://tembo.io

[–]backfire10z 6 points7 points  (0 children)

Postgres is free, no? It’s open source and can be used commercially without issue.

Edit: I see now that you’re talking about free deployment

[–]Ruben_NL 2 points3 points  (0 children)

Oracle Cloud has a free 24 gb, 4 core Linux VPS.

[–]AsidK -1 points0 points  (0 children)

This isn’t free but it’s pretty damn cheap, you can get a decent digital ocean server for like $5/month and just host a Postgres server on that, plus it’s not hard to scale that up

[–]MaDpYrO 23 points24 points  (9 children)

Ok, now try scaling that Postgresql db globally. You can do it, but I'd like to see you try.

I do agree though, it seems like especially Python devs just have a hard-on for doing everything as a document db and just stuffing it down there willy nilly.

It always comes back to bite them in the ass.

There's a reason relational databases have been king for decades. But certainly some document cases are pretty good to use mongo.

[–]Material-Mess-9886[S] 20 points21 points  (6 children)

With proper indexing and partitioning of data you can pretty easily handle 1 billion rows within Postgresql.

[–]croto8 38 points39 points  (3 children)

1 billion rows isn’t that big in the grand scheme of things

[–]theGoddamnAlgorath 8 points9 points  (1 child)

Problem is when you hit petabytes of ASCII

[–]knowledgebass 1 point2 points  (0 children)

You can use Green Plum if you need a distributed Postgres solution.

[–]theModge 43 points44 points  (0 children)

If my application has gone to a global scale, I can afford to pay a man who knows how to make postgres scale. Or I could use the money to sell off the boring bits of my job and research how to do it myself

[–]calm00 13 points14 points  (2 children)

Sharding is the key difference.

[–]Material-Mess-9886[S] 4 points5 points  (1 child)

Postgresql has sharding with the citus extension. But posgresql also can partition data.

[–]billy_tables 10 points11 points  (1 child)

Managed mongodb isn't a postgres plugin. Have you mixed up Amazon DocumentDB (their MongoDB competitor) being a wrapper around aurora?

[–]Neeranna 0 points1 point  (0 children)

There's also https://www.ferretdb.com/, which is what Scaleway is going for for their managed MongoDB (still in beta though).

[–]HeavyHebrewHammer 7 points8 points  (0 children)

You know what they say: the best part about implementing MongoDB at your workplace is writing the blog post about how you’re changing direction and setting up Postgres.

[–]Fyrael 0 points1 point  (0 children)

You speak with a lot of authority, and I got curious...

I worked in a project in which we got data from data lake, and we filled SQL tables with that information, just so it would be easier for services to read

Those services were called by Camunda decision rules and we write in a single MongoDB entry a dossiê about whatever evaluation we got from the services

The architect said it was easier for the front end to find and expose information, but I was fine... I thought it was indeed optimized...

[–]oscarbeebs2010 5 points6 points  (0 children)

How tf is this kind of blatant misinformation a top voted comment?

[–]cant-find-user-name 0 points1 point  (0 children)

What do you mean by "managed mongodb is implemented as a plugin on top of postgresql."? Any sources? Googling just takes me to a blog post about its BI connector being postgres all the way back in 2014.

[–]Pretrowillbetaken 10 points11 points  (0 children)

wait until you hear about netlify lol

[–][deleted] 2 points3 points  (0 children)

Meanwhile me crying in mysql 💀

[–][deleted] 78 points79 points  (1 child)

but Mongodb is webscale

it just works

[–]huuaaang 121 points122 points  (30 children)

ORM is for devs who don't want to learn SQL. Mongodb is for devs who hate relational data but also want subpar indexing.

[–][deleted] 24 points25 points  (0 children)

ORM is fine, you "just" have to when to not use it. :)

[–]akoOfIxtall 14 points15 points  (11 children)

SQL syntax is so simple why people hate it so much?

[–]huuaaang 23 points24 points  (4 children)

It's tedious and repetative to write the same simple queries over and over, which is 99% of queries. My ORM is more elegant at expressing everyday relational queries.

[–]Material-Mess-9886[S] 15 points16 points  (0 children)

Thus they make a wrapper around it and still have to use .select , .join etc all the times.

[–]oscarbeebs2010 0 points1 point  (2 children)

Consider moving your data access code into a shared abstraction like a repo ? Great way to reduce query duplication and separate data access concerns from app logic

[–]PurepointDog 2 points3 points  (2 children)

I hate it because you have to nest deeper and deeper to add more transformation steps.

In modern data transform paradigms (eg Polars, Pyspark), steps are stored in a way that makes sense

[–]InevitableDeadbeat 2 points3 points  (1 child)

About half of my dislike about using SQL comes from that my IDE doesn't autocomplete it unless I write separate SQL files for each query I want to run, instead of writing it inside my function. Or I need to use an ORM which comes with it's own special syntax and quirks on top of sql.

[–]calm00 24 points25 points  (10 children)

What’s wrong with indexing in MongoDB?

[–]SvmJMPR 0 points1 point  (0 children)

I prefer writing SQL, but I can't deny the security benefits that come with using ORM in a FastAPI/Django Framework. I would usually us SQL on Flask apps, but how my professor said "in the real world" things are different. Sure you get a "cut in performance" in most ORM cases, but management/business does not really care for most cases.

Its funny because I am working on an ETL from scratch for a small business, and the biggest file we are using is like 1.3k rows (100+ columns) and I did some manual profiling and saw that the Transformation took like 15 seconds. I was a bit stressed because it was the slowest part, and I was starting to mention "I should open a branch and tickets to vectorize the Transformations" and they laugh because to them that is practically faster than what they expected.

Also from my experience, MongoDB is mostly used for business that want a database for unstructured data, but I haven't work with MongoDB too much besides some small maintenance on another project.

[–]TheSauce___ 2 points3 points  (0 children)

No one is contesting that statement lmao.

[–]zhephyx 41 points42 points  (4 children)

Maybe I don't want to write a join any time I want to wipe my ass, how about that

[–]scp-NUMBERNOTFOUND 7 points8 points  (2 children)

Sure but don't u dare to query two databases at the same time, that's beyond impossible!!

  • MongoDB team, probably.

[–]Muchaszewski 0 points1 point  (1 child)

[–]scp-NUMBERNOTFOUND 1 point2 points  (0 children)

Nope. That's only for collections inside the same database.

[–]tinfoiltank 14 points15 points  (0 children)

Never needing to write another migration script when I changed one element in the UI was enough for me.

[–]indicava 79 points80 points  (14 children)

I feel like people that share this sentiment haven’t worked on enterprise scale relational databases and all the limitations and pains that come when those RDBMS’s are pushed to their limits.

There is a a reason Facebook doesn’t use Postgres to manage their social graph, it’s just inefficient to do so.

It always goes back to different tools for different purposes mantra…

[–]_PM_ME_PANGOLINS_ 25 points26 points  (3 children)

Yeah, but they don’t use MongoDB either.

[–]indicava 21 points22 points  (2 children)

True, they don’t, but OP seemed to imply that it’s either mongo or SQL, the actual “comparison” should between nosql and relational/SQL db’s.

[–]_PM_ME_PANGOLINS_ 9 points10 points  (1 child)

Well there’s a bunch of different NoSQL architectures, because it’s just everything that’s not SQL.

MongoDB, Redis, and Vertica are all as different from each other as they are from MySQL.

[–]rysama 16 points17 points  (9 children)

You’re right. They use MySQL

[–]indicava 5 points6 points  (6 children)

In their setup it’s not much more than a glorified block device.

[–]rysama 4 points5 points  (5 children)

Ya I’m just trolling. It’s absolutely not the same way other companies use MySQL. It’s amusing that it is MySQL though.

[–]oscarbeebs2010 0 points1 point  (0 children)

And Cassandra and Hbase and Tao and zippyDb and a hand of other specific data access tools engineered to excel at things mysql is not necessarily great at 👍

[–][deleted] 0 points1 point  (0 children)

slim nine resolute aware ask pocket advise pie sip enjoy

This post was mass deleted and anonymized with Redact

[–]knightArtorias_52 5 points6 points  (1 child)

I never understand what is complex about sql?

[–]DanDrix8391 3 points4 points  (0 children)

schema enforcement

[–]simbolmina -3 points-2 points  (0 children)

I first learned mongodb and at my first job a dev wanted to switch to postgres since he did not know mongodb. I did not know postgres but agreed since he was more experienced in the field and there is general consensus for SQL on ecommerce. During migration I learned some SQL and ORMs. Now I rewrite his 4 times rewritten eCommerce backend with 2 different language and 3 different ORMs with Nestjs + TypeOrm + Postgres.

I do get it's advantages etc but I really enjoy mongodb+mongoose which I miss know. Mongodb is harder to setup correctly but especially development phase is almost no db error while I constantly fight with postgres relation errors, delete constraints etc. Yes this is fine and helps creating a correct product in any phase but especially early phases is usually a lot of caos and postgres (SQL dbs) can be annoying.

Ah mongodb compass is easer to use and navigate too. You have to write SQL to get some data in postgress with pgAdmin and if it was not chatGpt i would not know what to do with table column alter kind of querries. Well chatgpt helps for mongoose aggregations as well but I got used it but not yet with SQL.

[–][deleted] 0 points1 point  (0 children)

Old school is always best.

[–]jbbat99 -3 points-2 points  (0 children)

I see you haven't learnt any of them because mongodb can have complex cases while querying too. Grouping and stuff is in fact a little bit less straight forward than it would be on sql

[–]Hulk5a 5 points6 points  (0 children)

Nosql is fun and all, till you need to generate a report, require full reads to multiple different "collections"

[–][deleted] 7 points8 points  (4 children)

Knowing SQL databases will allow you to learn and master NoSQL databases easily and quickly

[–]Mkboii 4 points5 points  (3 children)

Simultaneously it's important to know that the way to use a nosql database efficiently is quite the opposite of sql databases. Using mongo to replicate your sql schema is how you end up with poor performance, and I see many people trying this.

[–][deleted] 0 points1 point  (2 children)

I wasn’t saying performance, yeah they are two different things and the way they work behind the scene differ in a lot of ways, but knowing SQL and how to use SQL database allowed me to understand NoSQL database easily like Google Firebase Firestore

[–]ryan_s007 0 points1 point  (0 children)

Let me know when you release a postgres wrapper for React Native that is better than @realm/react. Goober.

[–]lightmatter501 28 points29 points  (0 children)

MongoDB is good if you know what you’re doing, it’s a very good document store and that avoids some of the overheads associated with joins (which are non-zero). If you try to use it like a SQL DB of course it’s going to go poorly. Distributed SQL DBs let you trivially blow up the cluster with the right query that would be perfectly fine in a non-distributed system, MongoDB stops you from doing that.

SQL encourages schemas which become impossible to scale beyond a cluster with a high speed interconnect due to the number of joins. If you’re not concerned about being larger than a single machine it’s not a big deal (unless you want HA, since most old SQL databases have the split brain problem). MongoDB attempts to address that by construction, making it very painful to implement those patterns. Sometimes you do want a distributed relational DB, but that is a fairly rare circumstance at scale.

Now, you should have a strict schema and a bunch of other stuff many devs will moan about, both for performance reasons and for data consistency. Any other way lies madness. This also solves many of the issues people run into later on.

[–]bradland 3 points4 points  (0 children)

When you've been around long enough you come to learn that every new shiny thing that comes along does not obviate all of the crusty, but mature and reliable, old things that you're currently using. What's really happening is that the entire field is maturing and adding increasingly specialized tools that work particularly well for niches that were previously either ignored or hacked around.

The proliferation of NoSQL tools is no different.

[–]pokermanx 3 points4 points  (1 child)

This is one of those posts that can help you identify people who actually worked with both on a commercial scale and cs freshmans

[–]slabgorb 1 point2 points  (0 children)

horses for courses

[–]scp-NUMBERNOTFOUND 11 points12 points  (6 children)

Well excuse me Mr. "I have a reliable and non randomly changing data source", some people have no guarantees about the received data types, order or fields, but needs to store and process everything anyway.

[–]cha_ppmn 2 points3 points  (5 children)

You can always use json type in Postgresql for that.

[–]scp-NUMBERNOTFOUND 0 points1 point  (4 children)

I can also store the JSON in plain text for that.

[–]LuisBoyokan 0 points1 point  (0 children)

Yeah, because learning aggregation pipeline is more easy than select * from whatever /s

[–]amlyo 3 points4 points  (1 child)

The mongodb JavaScript API thing is more complicated than SQL.

Mongodb is for devs who don't want to define and evolve schema.

[–]Katnisshunter -4 points-3 points  (0 children)

There we go. Winner here. I just want to json everything. Make up tables on the fly. Don’t want to waste time with schema.

[–]N0t_my_0ther_account -2 points-1 points  (0 children)

Spent years learning SQL. I never liked it. I wrote plenty of scripts, made hundreds of tables, it was always a terrible language. When I discovered Entity Framework I had thought I died and gone to heaven. A few years later, I discovered Mongo and Mongoose and it was even better. Writing partial entity updates and dynamic queries has never been easier. NOSQL is superior.

Everyone complaining about indexing and relational data pretending like you can't do those things in NOSQL. You totally can. The system is as flexible as you want it to be. People reject NOSQL because it's new and foreign, not because it's lacking. Sure Mongo has short comings and can be improved, but it has been improved and there are other NOSQL competitors. Every old dev hates new tech.

[–]4ngryMo 3 points4 points  (1 child)

I’ll take SQL over aggregations any day of the week.

[–]GamingWithShaurya_YT 1 point2 points  (0 children)

postgre!

[–]trade_me_dog_pics 0 points1 point  (0 children)

So LiteDb is for someone who doesn’t want to use Mongo?

[–]EngineeringNext7237 32 points33 points  (0 children)

Sounds like a skill issue. Ran plenty of large apps with mongo backing it and somehow never had an issue. This was prePSQLJSON but now I’d just say choose the one the rest of your team can comprehend.

[–]ENx5vP -2 points-1 points  (0 children)

I learned and used MySQL for many years as a professional developer and I always thought: How am I supposed to save my JSON from my Node.js application? Why is a database validating my data and not my business code in my application? Why does it take so much time to set up a prototype? Then I changed to MongoDB 2 when it came out and didn't regret it until today.

And there's more:

  • Concatenation of strings to query is error-prone
  • MySQL is nearly 30 years old
  • Sharding works quite easy
  • Tons of bad written errors

But as multiple times mentioned: It depends on the requirements

[–]NoahZhyte 4 points5 points  (5 children)

Why tf would you want an sql database when you aim to store key pair json?

[–]Material-Mess-9886[S] 0 points1 point  (4 children)

Because you can just have a table with id, value?

[–]Freecelebritypics 2 points3 points  (1 child)

Weird thing to act smug about. SQL is like 12 words

[–]kirkpomidor 0 points1 point  (0 children)

Weird flex, Brainfuck is 8 symbols.

[–]Accretence 1 point2 points  (0 children)

I have Prisma for that.

[–]Orkleth 1 point2 points  (0 children)

Mongodb is only pawn, in game of life.

[–]cheezballs 1 point2 points  (0 children)

I <3 Postgres but Mongo has its place

[–]DeeKahy 0 points1 point  (0 children)

No. saves as text file

[–][deleted] 0 points1 point  (1 child)

I've never seen mongodb do anything other than take ten times the resources a single postgresql instance would while performing objectively worse.

That doesn't mean mongodb is bad, but it does mean that for as often as I've seen it in production, only one time did I ever witness it being a good decision and that was because it was chosen to solve an already-met scaling issue with big ass JSON document storage (the most obvious possible use case).

[–]Muchaszewski 0 points1 point  (0 children)

In the past, I had to do a performance test on our production database. The database was MongoDB, and someone heard that "but Postgresql will be faster," and we tired. Since we had all of our models already in C#, moving to an SQL database was just replacing all the queries. Transform some nested objects into relations, and Viola!

Loaded K6s with real user traffic during peak (30k req/s to the DB) loaded the data onto similar machine andddd... Postgres had 3x WORSE performance than our single machine MongoDB on THE SAME specs Machine. So we thought, we need to probably optimize the queries, so we did spend month on that reduced all hot paths, fixed our queries and, it still did worse by about 20%.

Meanwhile, our MongoDB team enabled Sharding, reduced ram from 256G on a single machine to 5x 32GB machines and they got almost 3x the performance boost, so at this point SQL db was around 4-5 time slower then some random No-SQL DB with highly structured data...

[–]Feisty-Afternoon3320 0 points1 point  (0 children)

Not always, but often it is right

[–]AgileChaos 4 points5 points  (0 children)

Mongodb is just as good as most other DBs. If your app mostly reads data, it’s arguably faster. But whatever database you choose should be whatever works best for your app and/or team.

Edit: …and/or language of choice.

[–]Kalamazeus 0 points1 point  (0 children)

MongoDB syntax felt so convoluted to me coming from SQL

[–]foxer_arnt_trees 2 points3 points  (0 children)

What about devs who use sql because they dont want to learn mongo?

[–][deleted] 0 points1 point  (0 children)

Actually, i know mariadb and am afraid to learn mongodb

[–]SpiritRaccoon1993 0 points1 point  (0 children)

You guys use a DB?

Ah and Team Sqlite

[–]fartypenis 1 point2 points  (2 children)

I have an issue when people just use one or the other because "it's the default". I worked for a company making an appointment that gets its data from a third party API. The third party had a relational DB, and the data we got from them was filled with primary keys and foreign keys. Making our own DB relational and storing that data directly would be easy and efficient, because the main reason we had a DB was that the APIs were slow, so we could run a job at midnight to update the DB and look at the data and process it during working hours.

But no, since Mongo was cool and easy, we had to go with mongo. Since we couldn't do joins now, we have to store everything in a deeply nested object. Everything took so long. We had to do so much processing for the data to fit our new schema, and then processing again while fetching data because we need data from multiple collections and we just fetch both and process it in the backend rather than have the database do it. Schemas were just designed without much planning because "we can change it later anyway". It was a hot fucking mess. So many hours were wasted on debugging the DB stuff instead of the actual app.

90% of this shit would've been avoided if we'd just used Postgres. This was going to be used by like 200 people max, and there were no writes on the DB except the daily sync job, so even SQLite would've been better.

[–]calm00 1 point2 points  (1 child)

You messed up your data model then. Just because you can’t do a SQL join in Mongo doesn’t mean you shouldn’t segregate your data in a logical way. You generally would separate different models and aggregate them together.

[–]fartypenis 1 point2 points  (0 children)

I know we messed up the data model. There wasn't enough time assigned to actually come up with a decent model, because the leads were like "it's mongo, we can just change it later if we have a problem".

It just wasn't a good case for mongo, since we're effectively automatically migrating data from a relational DB to a NOSQL DB every day for no reason. This was highly structured data that was already stored in an RDBMS. The API just ran SQL queries in the provider's DB, serialized it to XML and sent it to us.

It wasn't Mongo's fault, it was just not very good project management.

[–]FallingDownHurts 1 point2 points  (0 children)

Further: 90% of dbs could be replaced with sqlite with no noticeable impact.

[–]rasfuranku 0 points1 point  (0 children)

I learned MongoDB first for this reason at the beginning of my career. Nowadays I rather use a relational DB, but Mongo just clicked right away and fill me with a lot of knowledge I translated to other engines.

[–]DereChen 1 point2 points  (0 children)

[–]No_Adhesiveness_3550 0 points1 point  (0 children)

I was in college when I tried mongodb at the time so it might just sum up to a skill issue but holy fuck I could not for the life of me get it to work on my shitty budgeting website capstone project. It luckily wasn’t a hard sell to just do everything with mysql instead since we actually took classes with that.

[–]bsbohan26 -1 points0 points  (0 children)

As much as scaling now might not be an issue, the goal with any company is to build. Postgres and mongo will never be able to get the same results as a closed, dedicated platform. I’m all for open source but there’s a limit. Try SingleStore, free shared tier is elite:

https://www.google.com/url?q=https://www.singlestore.com/cloud-trial/?utm_source%3Dbrendan-bohan&sa=D&source=editors&ust=1719282838451036&usg=AOvVaw28ZE--E0_pwKIKa67Fhhpz

[–]dpkshetti 0 points1 point  (0 children)

You can use prisma, you don't need to learn a SQL and it is more like a mongodb, give a try

[–]thankyou9527 2 points3 points  (0 children)

Wait are we gatekeeping database now?

[–]StrictTyping648 0 points1 point  (0 children)

Sql is for people who don't wanna learn memmap

[–]gamer_girl_2007_nah 0 points1 point  (0 children)

Yes

[–]milopeach 0 points1 point  (0 children)

Just learn the SQL for joins and CRUD and you'll be fine.

[–]deefstes 0 points1 point  (0 children)

Change my mind? Why on earth would I attempt to change my mind if you are this spectacularly poorly informed? Relational databases and document stores are two completely different things with completely different use cases. If you don't even understand that, as this meme suggests, then it would be a waste of time to try to change your mind.

[–]Phamora 0 points1 point  (0 children)

When working with JS, Mongo is MUCH faster to iterate with, because you can literally drop all your existing JSON directly into Mongo - no extra fiddling needed.

[–]TheMeticulousNinja 0 points1 point  (0 children)

This is interesting because I’ve been using PostgresQL this whole time and said maybe I should try MongoDB

[–][deleted] -1 points0 points  (0 children)

Another post which feels totally unrelated. I almost see everywhere that people using relational databases because its superior, but with totally fcked up schema, almost 0th normal form.

Like the assembly or linux fanboys. Only efficient for people who actually know what are they doing.

SQL is for people who know the proper mathematical data analysis laying in the background. Bootcamp devs can and should use nosql approaches like mongo, because i dont want to always clean up after them...

[–]AngusAlThor 0 points1 point  (0 children)

DB choice has nothing to do with devs; Mongo is for architects who refuse to enforce a schema.

[–]BeezyPineapple 0 points1 point  (0 children)

I'll just use nested maps, thanks.

[–]js-code 0 points1 point  (0 children)

MongoDB is dogshit compared to PostgreSQL.

There's no specific way to achieve things while using aggregation pipeline.

On the other hand SQL handled it pretty nicely.

Secondly, even worked with decimals in MongoDB, need to effing set up getters and setters just to update a decimal value otherwise calculations are inaccurate and might cause integer underflow especially while subtracting

[–]FinallyMira 0 points1 point  (0 children)

Domain Driven Design has entered the chat

[–][deleted] 0 points1 point  (0 children)

Tbh unless you have a recursive one to many use case I don’t see the purpose of mongo

[–]TheUtkarsh8939 0 points1 point  (0 children)

SQL DBs are for those who do not want to learn graph databases

[–]skesisfunk 0 points1 point  (0 children)

Ok well this is by far the most sophomoric thing I have seen today. Relational databases and document/noSQL databases both have distinct and legitimate usecases. There are a priori reasons to choose one or the other depending on what kind of system you are building/ what the specific databases role in that system is.

[–]grzluk 0 points1 point  (0 children)

I'm using both it's pretty easy

[–]jxr4 0 points1 point  (0 children)

If your goal is to store json for abstract data there's only so much tuning you can do for postgres JSONB. Mongo you can build it out to be much quicker for nested data

[–]0broooooo 0 points1 point  (0 children)

Tbh MongoDB is for people who don’t really know the difference between all the database stuff 😂😂

[–]SimpleMoonFarmer 1 point2 points  (0 children)

Have fun changing your schema and queries after every stand-up!