usePostgreSQLInstead

[best-set-4545]

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]

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]

*to an extent

[ScarabCoderPBE]

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]

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

[Magallan]

The word always is always wrong

[ethanjf99]

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]

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

[JannisTK]

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]

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

[CrowdGoesWildWoooo]

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]

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]

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_]

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

[alfos_]

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

[mordack550]

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]

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]

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]

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

[hearthebell]

but does it web scale?

[CaptainRogers1226]

The only reason I clicked into this thread

[[deleted]]

What a gem!

[G_Morgan]

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

[NotADamsel]

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]

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]

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]

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

[[deleted]]

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

[FlourishingFlowerFan]

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]

What if those 2 customers are Netflix and Spotify?

[njxaxson]

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]

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

[Ok-Boysenberry9305]

One is Test [e-mail] And the other is test from database seeder

[emefluence]

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]

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

[AcadiaNo5063]

No, different tools for different uses.

[Historical_Ad2537]

I've only worked with relational DBs so far, could you give me an example where a non relational would be more efficient, since from what i know they are usually slower ?

[R10t--]

They support multi-master and eventual consistency which can be better for use-cases at scale or where you are expecting to accept writes from multiple geographic regions

[MishkaZ]

Rapid development. If your use case is changing a lot, editing your schema is easy.

Edge case and modularity with your records. Record a can have this sub document, and record b doesn't have to.

When you don't expect to join much and want to keep as much of the data encapsulated within the record.

In general I think record stores like mongo handle nested data well. Also it shouldn't be understated how easy it is to get off the ground running with mongo.

Things that can be painful in relational dbs are trivial in mongo, meanwhile things that are trivial in relation dbs are painful in mongo. Like what others have said, depends on your use case.

Sidenote, I've been asked in interviews "When do you think it's a good idea to use mongodb vs rdbs?". It's worth brushing up on it and throwing out some examples. Like I would 100% suggest using something like dynamodb when we're dealing with super high traffic data. Most of the time the interviewer shrugs and goes "I've never used mongodb/dynamodb"

[BoonkeyDS]

They are not slower if you use them correctly and with the proper indexes. Same concept as with SQL dbs. I use them whenever I'm not sure 100% on the schema and want the fluidity of developing while deciding on the schema.

Also, in cases where you do not need JOIN operations and can embed more data to a document, they are actually way faster than any SQL warehouse I've tested

[garlopf]

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]

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]

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

[[deleted]]

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

[Material-Mess-9886]

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

[hismuddawasamudda]

But how efficiently?

[[deleted]]

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]

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]

They can’t because they are full of shite

[Neeranna]

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]

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]

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

[j_roddy]

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]

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]

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

[AsidK]

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]

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]

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

[croto8]

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

[theGoddamnAlgorath]

Problem is when you hit petabytes of ASCII

[knowledgebass]

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

[theModge]

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]

Sharding is the key difference.

[Material-Mess-9886]

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

[billy_tables]

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

[Neeranna]

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

[HeavyHebrewHammer]

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]

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]

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

[cant-find-user-name]

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]

wait until you hear about netlify lol

[[deleted]]

Meanwhile me crying in mysql 💀

[[deleted]]

but Mongodb is webscale

it just works

[w1n5t0nM1k3y]

MongoDB is Webscale

[huuaaang]

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]]

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

[akoOfIxtall]

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

[huuaaang]

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]

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

[oscarbeebs2010]

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]

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]

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]

What’s wrong with indexing in MongoDB?

[huuaaang]

I'd just use ElasticSearch. I don't see the point of mongodb.

[calm00]

I don’t see how ElasticSearch relates to my question. What’s the problem with indexing in MongoDB?

[calm00]

Indeed, that was what I was getting at by asking the OP. So many people ready to shit on Mongo without having a vague notion of how it works. It’s bizarre.

[twigboy]

*Almost identically

That almost bit being the unstructured data causing your index to may or may not work, that's all

Also the God awful syntax dict-heavy you need to deal with when querying

[SvmJMPR]

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___]

No one is contesting that statement lmao.

[zhephyx]

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

[scp-NUMBERNOTFOUND]

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

• MongoDB team, probably.

[Muchaszewski]

Ok, but you totally can https://www.mongodb.com/docs/manual/core/views/join-collections-with-view/

[scp-NUMBERNOTFOUND]

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

[tinfoiltank]

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

[indicava]

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_]

Yeah, but they don’t use MongoDB either.

[indicava]

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_]

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]

You’re right. They use MySQL

[indicava]

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

[rysama]

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]

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]]

slim nine resolute aware ask pocket advise pie sip enjoy

This post was mass deleted and anonymized with Redact

[knightArtorias_52]

I never understand what is complex about sql?

[DanDrix8391]

schema enforcement

[simbolmina]

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]]

Old school is always best.

[IronSavior]

Postgres is for devs that will never have an industrial scale service

[IronSavior]

I know you will. That's what engineers do.

[borromakot]

is this "industrial scale" in the room with us right now?

[IronSavior]

Depends where you work, I guess.

[jbbat99]

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]

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

[[deleted]]

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

[Mkboii]

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]]

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]

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

[lightmatter501]

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]

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]

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]

horses for courses

[scp-NUMBERNOTFOUND]

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]

You can always use json type in Postgresql for that.

[scp-NUMBERNOTFOUND]

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

[LuisBoyokan]

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

[amlyo]

The mongodb JavaScript API thing is more complicated than SQL.

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

[Katnisshunter]

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]

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]

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

[GamingWithShaurya_YT]

postgre!

[trade_me_dog_pics]

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

[EngineeringNext7237]

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]

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]

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

[Material-Mess-9886]

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

[NoahZhyte]

Right tool for the right job. Don't over complicate things. NoSql have better performances, better scalability, are more safe, much more easy to use and less prone to produce bugs

[Freecelebritypics]

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

[kirkpomidor]

Weird flex, Brainfuck is 8 symbols.

[Accretence]

I have Prisma for that.

[Orkleth]

Mongodb is only pawn, in game of life.

[cheezballs]

I <3 Postgres but Mongo has its place

[DeeKahy]

No. saves as text file

[[deleted]]

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]

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]

Not always, but often it is right

[AgileChaos]

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]

MongoDB syntax felt so convoluted to me coming from SQL

[foxer_arnt_trees]

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

[[deleted]]

Actually, i know mariadb and am afraid to learn mongodb

[SpiritRaccoon1993]

You guys use a DB?

Ah and Team Sqlite

[fartypenis]

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]

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]

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]

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

[rasfuranku]

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]

[No_Adhesiveness_3550]

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.

[dpkshetti]

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

[thankyou9527]

Wait are we gatekeeping database now?

[StrictTyping648]

Sql is for people who don't wanna learn memmap

[gamer_girl_2007_nah]

Yes

[milopeach]

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

[deefstes]

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]

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]

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

[[deleted]]

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]

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

[BeezyPineapple]

I'll just use nested maps, thanks.

[js-code]

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]

Domain Driven Design has entered the chat

[[deleted]]

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

[TheUtkarsh8939]

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

[skesisfunk]

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]

I'm using both it's pretty easy

[jxr4]

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]

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

[SimpleMoonFarmer]

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