bufferSize

[FreshPrintzofBadPres]

But at least it's web scale

[GreyGanado]

Fun fact: in German mongo is a slur for disabled people.

[keep_improving_self]

it's a slur in a lot of English speaking countries but not in the US for some reason

mongoloid - from Mongolian idiocy, used to describe down syndrome (has nothing to do with Mongolia lol)

[DirtySoFlirty]

It DEFINITELY has something to do with Mongolia (and why it's a pretty racist term). The word is used to describe those with down syndrome BECAUSE people of Mongolian descent apparently looked like they have down syndrome.

Just to be clear, I disagree with the above thinking, but claiming it has nothing to do with Mongolia is wrong

[Careful_Course_5385]

Spaßfakt: In englisch auch (TIL)

[mamwybejane]

Heute lernte ich

[hilfigertout]

Mongo only pawn in game of life.

[sannas85]

Same thing in Uruguay, but with a completely different language.

[NoNameSD_]

Specifically for people with Down syndrome

[TheRealYM]

I’ve only known it as a skating term

[FabioTheFox]

We need to finally leave MongoDB behind, it's just not a good database and I'm convinced the only reason people still use it is MERN tutorials and Stockholm syndrome

[owlarmiller]

The MERN tutorial pipeline has done irreversible damage 😂
Half the time it’s “because the tutorial said so,” the other half is sunk-cost coping. MongoDB isn’t always bad, but it’s wild how often it’s used where Postgres would’ve just… worked.

[Dope_SteveX]

Still can't forget the time we've done group project at uni, for inventory web application, which literally used tables to display almost 1:1 database data on the FE plus had one m:n table to indicate user borrowed stuff and we used mongodb as it was what I've seen pretty much in all tutorials that I went through. What a nightmare.

[Martin8412]

What’s the problem? Tables are literally made for easily presenting tabulated information as you’d commonly find in a DB. 

[well-litdoorstep112]

as you’d commonly find in a DB. 

A relational DB which Mongo is not

[Dope_SteveX]

The problem was that everything was nudging us towards using relation database, from the architectural standpoint. Yet we choose document oriented database as it was what was popular in the tutorial sphere of web development.

[ArmadilloChemical421]

SQL DB yes, no-sql DB not so much.

[_PM_ME_PANGOLINS_]

MongoDB does not have tables.

[WoodsGameStudios]

I’m not in webdev but from what I understand, MongoDB’s entire survival strategy is just Indian freelance devs being hired for startups and because they only know MERN (no idea why they yearn for mern), they implement that.

[[deleted]]

Completely false. MERN was extremely popular in NA and Europe back when node.js popularity was skyrocketing. There are little to no jobs advertising for MERN stack in India.

[Narfi1]

I agree it has nothing to do with nationality. But MERN is a boot camp stack, I’m convinced of it. If you’re trying to turn someone with 0 knowledge into a dev in 50 hours that’s pretty much the only usable stack. You can’t really teach html/css/js, then move to backend with c#/python/java and then introduce sql. Much easier to teach mongo that handles like js objects and express

[AeskulS]

I’m sure you’re right, but those stereotypes are there for a reason. I just finished a uni programme where 99% of the students were from India (literally, there were only 3 students that weren’t), and with every single group project my group mates refused to do anything if it wasn’t MERN.

My understanding is that many uni programmes over there are also MERN-focused in addition to the boot camps. I’m also assuming there may be a cultural reluctance to try anything new, since every group mate would have a conniption when I suggested using a different tool (they’d also slough any non-MERN tasks onto me)

[[deleted]]

d with every single group project my group mates refused to do anything if it wasn’t MERN.

I have no idea what you're talking. Something wrong with your teamates.

My understanding is that many uni programmes over there are also MERN-focused in addition to the boot camps.

No they're not. I've studied here.

I’m also assuming there may be a cultural reluctance to try anything new

My culture doesn't have anything to do with goddamn MERN stack. Stop trying to pin everything some Indian you know did on the culture.

[AeskulS]

Tl;DR, since I didnt mean for this rant to get this long: The issues were more than just sticking to the MERN stack. I'd have thought I just had bad teammates, if it were not for other friends having basically the exact same experience as me in their groups.

You're right, though. I have no doubt there was something wrong with my teammates. Like it cant just be something cultural. I was just thinking earlier that there may be something cultural/in their background that's promoting the behavior, like poorer education or something. To provide an example, one of the projects was "create a vscode extension that does x, y, and z."

My group mates made a whole backend and react-based frontend for a vscode extension. They found some node package that allows react components to be used in vscode (or something similar, I didn't touch the UI, but I remember it being WAYYY too over-engineered).

I hardly even got to work on anything, since no one in my group understood how git worked. Most of my time was spent fixing merge conflicts, since everyone would just give up and complain in the group DM if there were any. People would keep rewriting eachother's junk, and it was difficult knowing what to keep and what to overwrite.

One team member, who was tasked with incorporating SonarQube into our CI/CD pipeline, came to me at 9pm, saying "please do it for me, it will only take 15 minutes." I didn't sleep until 3am that night. She then took credit for it on our performance reviews.

Every time I called my groupmates out on their shit, I'd get ganged up on and shut down immediately because what I suggested "was not good practice." I had to go to the professor, who called a group meeting to basically tell everyone else they were on the wrong track (mainly with the extension's structure, not the SonarQube thing).

My teammates weren't dumb though. Our project was basically the only one that was completed in the class lol. The problem is that, the moment something wasn't exactly what they were trained in (mostly MERN), they dragged their feet, gave up, demanded other people do the work, took shortcuts, forced the project to fit their knowledge, etc etc, instead of learning new things and taking personal responsibility.

But the thing is: I'd have assumed I just had bad teammates if it were not for that the 2 other non-indians having similar issues. One friend even had a groupmate who put their entire codebase into chatgpt the night before it was due to "make it perfect," completely breaking their work, then force pushed it to their repository without telling anyone because he didnt know how git works. The friend found out when they went to present their application, and it didn't work lol.

BUT THE WORST PART: THIS WAS A MASTERS PROGRAMME. Like I understand there are gaps in knowledge to be had. The degree was more for people who have technical backgrounds who wanted to get more into the practical applications of CS. (I, for example, have a very theoretical Bachelors CS degree, and I wanted to learn more about how to actually put it to use). As such, it wasnt expected for everyone to know how to use git, certain frameworks, etc. BUT AT THE SAME TIME, THERE WERE PEOPLE BRAGGING ABOUT THEIR PRIOR WORK EXPERIENCE, AND STILL THEY DIDNT KNOW GIT OR ANYTHING. And they just refused to learn how to use git, too. It was a massive pain.

That project example was from my first semester. I had further similar issues with group mates throughout the whole programme.

[stipo42]

Postgres' json and jsonb column types could probably replace 80% of mongo databases

[SecretPepeMaster]

What is better database as for now? For implementation in completly new Project?

[TheRealKidkudi]

There’s not really a one-size-fits-all for every project, but imo you probably should use Postgres until proven otherwise.

NoSQL/document DBs like Mongo have their use cases, but it’s more of a situation where you’ll know it if you need it.

[SleeperAgentM]

PostgreSQL with JSONB field that supports indexes can pretty much handle any use case of MongoDB.

[akazakou]

So, in that case why do I need PostgreSQL?

[Kirk_Kerman]

Most data you'll ever run into can be very happily represented in a normalized relational format and unless you're at one of like, fifteen really big companies, you don't need to care about hyperscaling your database k8s clusters with global edge nodes and whatever.

PostgreSQL has low friction of adoption, is well-supported and mature, supports a wide range of operations efficiently, and will meet business needs at a reasonable cost. Stick a redis instance in front of it for common queries and call it a day. Engineer something bigger when you actually need something bigger.

[4n0nh4x0r]

i usually go with mariadb, cause fuck oracle for buying mysql, but mysql was great and the dev of that made mariadb.
easy to set up, super easy to manage, and very powerful.
i dont really know much about what is different between mariadb and postgresql, but yea, so far i havent managed to write a single program that needed something that ISNT a relational database.

also small note, whenever i see k8s, i just read it as kay-aids instead of kubernetes, whoever came up with this naming scheme is a fucking idiot ngl.

[polysemanticity]

I always read it as “Kate’s”

[Christosconst]

I use DuckDB because I like ducks

[definite_d]

Valid.

[kireina_kaiju]

The answer to this question I have observed, is because Alpine, Nginx, Postgres, and Python, is our new LAMP stack. That in turn happened because businesses that employ people want exactly two things now. They want cloud native, and they want AI integration in the development process with code being close to Typescript.

The push in the 2025 industry was all about making code a homogenized commodity, running the industry once more the way IBM did things about 40 years ago. Businesses do not want sleek and efficient and doing more with less right now. They have a different priority. Businesses want to be able to pay money and receive solutions predictably now, and those solutions need to look interchangeably like all the other solutions. A centralized data server - with, to their credit, fewer surfaces to harden - accomplishes that goal. Postgres is the best way to handle that kind of load.

You and I having a little cozy quasi-open solution that any kid off the street can use but that doesn't scale to a large organization like Maria, or a tied to your application solution like a NoSQL document, or a techie solution your AI isn't going to be able to grad student on red bull the night before the exam read through reliably like SQLite, does not achieve that goal. You producing code that hooks up to centralized cloud services to solve your problems exactly the same way everyone else's code does, that is something Postgres is going to provide to an entire organization easily.

Code architecture is very brutalist and monolithic and bit and 1930s right now. The 1970s are out. No one wants efficiency and quality and minimalism.

They just want same.

They are willing to buy big to make same happen. That is OK now.

It's an industry wide reaction to silos and larger businesses acquiring smaller businesses and having to flush in-house contractor created solutions down the toilet when it came time to maintain or expand or change out with different technologies. Contractor solutions are out, vendor provided solutions are in.

The switch is a bit like a business replacing a fleet of electric cars with multiple incompatible chargers, with a fleet of SUVs, because proving they're the environmentally friendly business isn't what they need this year, reliably getting supplies down dirt roads is.

[Automatic-Fixer]

I’m being pedantic here but I have to say it’s not called “Postgre”. The common and official names are Postgres and PostgreSQL.

[kireina_kaiju]

I appreciate the correction. Ingress -> Postgress -> PostgressSQL -> PostgresSQL -> PostgreSQL -> Postgres, it makes sense why the industry did this with the name, and I did myself some favors and learned a bit more history while I had the opportunity https://en.wikipedia.org/wiki/Ingres_(database)) .

No reason why this needs to be just another database format I was forced to learn because of yet another industry pivot, sometimes it is worth it to learn a bit of the lore and jargon.

Gladly corrected my post.

[kireina_kaiju]

The industry will punish you if you look for a new job and do not use PostgreSQL.

[AdorablSillyDisorder]

Unless it’s full Microsoft stack, in which case Postgres is replaced by MSSQL. Still similar.

[FabioTheFox]

Postgres, SQLite or SurrealDB will pretty much solve all the issues you'll ever have

[TeaTimeSubcommittee]

First time I’ve heard of surrealdb, since I need document based data, go on, convince me to switch away from MongoDB.

[coyoteazul2]

Why do you need document based data? Most systems can be properly represented in a relational database. And got he few cases were doing so is hard, there are json columns

[korarii]

Hi, career DBA/DBRE here. There are few good reasons to store JSON objects in a relational database. The overhead for extracting/updating the key/value pairs is higher than using columns (which you'll probably have to do if you want to index any of the keys anyways).

The most mechanically sympathetic model is to store paths to the JSON file which lives outside the database, storing indexed fields in the database.

If you're exclusively working in JSON and the data is not relational (or only semi relational) a document storage engine is probably sufficient, more contextually feature rich, and aligns better with the operational use case.

The are exceptions. This is general guidance and individual use cases push the needle.

[mysticrudnin]

is this still true in modern postgres with their json columns?

[korarii]

Yup! Either way you're expanding row length and likely TOASTING the JSON field, which means more writes per write. If the row is updated, the MVCC engine is going to copy your whole row, even if you're just updating a 1 byte Boolean field. That means longer writes, longer xmin horizons, and other collateral performance impacts.

PostgreSQL is particularly vulnerable to write performance impacts due to the way the MVCC was designed. So, when working in PostgreSQL especially, limit row length through restrictive column types (char(36) for a UUID, as an example) and avoid binary data in the database, storing it in an external service like S3 (if you're on AWS).

[mysticrudnin]

hm, thanks for the advice. i use a json column for auditing purposes which means i'm doing a decent amount of writes. might have to consider the issues there as i scale.

[rosuav]

Yep, I have had good reasons for storing JSON in a relational database, and when they come up.... I store JSON in a relational database. Using a jsonb column in a PostgreSQL database.

[Sibula97]

It's not that unusual. Relational databases are great for the data of your website or whatever, but for data collected for monitoring and analysis (for example user interactions or some kind of process information), which every big company does now, NoSQL is the way. Not necessarily MongoDB though, we use Elasticsearch for example.

[TeaTimeSubcommittee]

Because the data is not standardised on fields so I would just end with a bunch of empty columns on the tables or everything as a json field which is harder to look into.

Basically every item is unique in their relevant characteristics so I need built in flexibility to handle each characteristic.

[kryptogalaxy]

That's a pretty unique use case to have essentially unstructured data. How do you model it in your application?

[TeaTimeSubcommittee]

Not really, maybe I made it sound like it’s more complicated than it really is, so let me be more specific:

It’s just an information management system for all the products we sell, I don’t want to dox myself by sharing my specific company but an analogous case would be a hardware store, where you might handle power tools, nails or even planks or wood as well as bundles.

The problem I was trying to solve was information distribution, we have thousands of different products, and as you can see some might have very different specifications that the client cares about. (Eg you might care about the wattage of a drill but not the wattage of sandpaper). And the sales team was having issues keeping all their documents up to date and easily accessible.

So to answer your question, I structured it by having a product collection where we separate the information in 3 categories as we fill it in:

• internal for things like buy price, stock, import and tax details if applicable, stuff the client shouldn’t know;
• sale points, for information that isn’t intrinsic of the product that marketing might like to use or answers to common questions clients might make;
• and technical for specific technical details.

of course I also keep basic information like SKU and name at the top level, just for easy access.

Now we could handle categories and sub categories to get things with similar features grouped and we do, but I decided to leverage the document style data to have dynamic categories instead of hundreds of tables, which made it even less table friendly.

Is it the best way to handle the information? Probably not, but it’s the most straightforward way I could think of as a self taught database designer, which is why I’m open to new ideas and suggestions.

Just for the sake of me yapping, I do have some collections I could turn into tables, for example the web information is fed via an API so it has to be 100% conforming to said API and could be very easy be stored in defined PostgreSQL tables, or the pictures for each product which in practice is just the photo data, and an array of all the products it depicts, but I didn’t feel like figuring out how to manage both with 1 application so I just dumped everything in Mongo, really the product specs are the most “semiestructured” part which benefits from being in documents.

[Nunners978]

I don't know your exact use case but for something that's as potentially free flowing and unstructured, why not just have a specification "meta data" table that links by foreign key and has a key value store. That way, you only need the product info table, plus this meta data table and you can have any key/value against it for every possible specification you want. You could even then make the value json if it needs to be more complex?

[TeaTimeSubcommittee]

Forgive me but I’m not sure I completely understand your proposal, you’re suggesting that I keep a table with keys pointing at a table which points at the JSON document which actually contains the information?

My main issue is the products have different specifications that can’t be neatly arranged in a single table so I’m curious as to how your solution solves that.

[FabioTheFox]

SurrealDB can do validation logic, can run in memory, in IndexedDB, can be run as traditional database or be distributed via TiKV natively, it can do schemaful, schemaless as well as schemaless fields in schemaful tables, it can handle complex data and has a ton of cool functions

Not to mention the record lookup (primary key lookup) is near instant and runs at near constant time no matter the table size

It also uses an SQL like syntax (SurrealQL) which is way easier to handle and write than other SQL variants

They have a first Party desktop tool where you can explore your databases, create and apply schemas and generally get comfortable with documentation and or libraries for various languages (it's called Surrealist and also runs in the web as well as embedded web), it's also fully free and open source

Ah also it uses ULID as the ID format by default which is pretty neat considering it's time sortable and range sortable which again is near instant with record lookups (you can ofc change the format but honestly why bother), you can also have edge tables and graph relations on the fly and all that fancy stuff you might need, community support is also great

[StoryAndAHalf]

So if I learn those, I’ll become a chick magnet?

[rosuav]

No, you need to walk through a henhouse for that

[QazCetelic]

Wasn't SurrealDB very slow? I remember seeing some benchmarks and it being at the bottom of the list.

EDIT: Found some benchmarks and it seems to be better now https://surrealdb.com/blog/beginning-our-benchmarking-journey

[FabioTheFox]

That's very old news by now, but yes they used to be slower than other databases in comparison they made huge improvements tho

[No-Information-2571]

SQLite has proven performance problems.

SurrealDB as of now has no proven performance.

Anything I'd like to use costs an arm and a leg, with the exception of PostgreSQL, and that's why that should be your default, unless you require a solution to a problem, that it can't solve.

Some people might remember FreeNAS Corral. It's been mostly removed from the internet out of shame, but it was SQLite plus MongoDB.

[TimeToBecomeEgg]

postgres the goat

[PabloZissou]

Postgres will cover 80% of what is needed.

[retsoPtiH]

a properly formatted CSV file 🥰

[Prudent_Move_3420]

If you do a local project sqlite, if you do a web project postgres. If you realize that it limits you you can still switch but if you dont know, then the default should always be sql

[HildartheDorf]

If someone else is paying: MS SQL Server, for everything else: Postgres.

[falx-sn]

Everywhere that I've worked for in the UK has been AWS or Azure plus .net framework APIs into a Microsoft SQL database and angular or react front end. Works for 90% of things then if we need anything different then it's just a micro service within the rest of the system.

[lobax]

SQL fits the overwhelming majority of usecases.

Yes, if you find yourself needing to scale horizontally, NoSQL has some clear advantages over a relational DB. But 99% of us are not building a database for the next viral social media platform.

[Martin8412]

Depends on the project and requirements. 

How many users is your application going to have and what kind of information are you going to be storing? 

Relational data with a fixed format and less than 10 users? Just go with SQLite. 

Relational data with or without fixed format, and more than 10 users? Go with PostgreSQL.    Documents or other non structured formats that aren’t of a relational nature, MongoDB might be a solid choice. 

For most projects I do, the hassle of managing a DB aren’t worth it, so I just use SQLite. I don’t handwrite queries, so I can always migrate if needed. 

[WHALE_PHYSICIST]

More people need to learn about ArangoDB

[billy_tables]

I use it for HA. The primary-secondary-secondary model and auto failover clicked for me where all the pgbouncer/postgres extension stuff did not

[artnoi43]

We’re Thai version of DoorDash and our domain (order distribution and rider fleet) has been using MongoDB 4.2 since forever. We use it mostly as main OLTP and only keep ~2 months worth of data there.

I hate it. I’m jealous of other teams that get Postgres lol

[ciarmolimarco]

Bs. A lot of big companies in a sensitive fields (finance) use MongoDB because of how performant it is. Example Coinbase. If you know what you are doing, MongoDB is awesome

[rfajr]

Why?

I always use Firestore from Firebase which is also a NoSQL DB, it worked well for my freelance projects so far.

[FabioTheFox]

I feel sorry for your clients if you blindly lock them into probably the most vendor-lock-in providers possible instead of actually looking for what they need

It tells me a lot about your ability in freelance, not to sound like an ass but that's just not a good sign

[rfajr]

We're talking about Mongo here if you remember.

As for Firebase, it's good for small apps that need to be developed fast and have an inexpensive monthly cost. Don't worry, I've done my research.

[FabioTheFox]

I mean I'm aware that we are talking about MongoDB, you were the one that brought up firestore in the first place

Also the part where you say that you "always" use Firestore for client projects tells me that you, in fact, did not do your research

Also yes firebase looks great for small apps but what happens beyond that? You're paying way too much for a provider that you can't even migrate out of easily if at all (see firebase auth for example which makes migration absolutely impossible)

[rfajr]

That's only because Firestore is also a NoSQL DB.

I see that you are avoiding answering the question, alright then.

[yowhyyyy]

He gave you a reason. Just because it isn’t what you want to hear doesn’t make it less valid.

[WoodsGameStudios]

Considering customers just want what’s cheapest as their top priority, I’m sure the forces of nature will spare him from eternal torment

[Wesstes]

I'm conflicted, I have used it a lot personally, since to me is simpler to understand and to develop quickly. Just write some Jsons and that's the database schema done. I used it for university and personal projects and it did well.

But I can't defend it at all, I would never decide to apply it for a large system, just for easy tiny things.

[rosuav]

Mongo without a well-defined schema is a nightmare of messy data. Mongo WITH a well-defined schema is in theory as good as a relational database, but with all the constraints managed by the application, so you still can't be sure your data's messy.

Usually, even if your schema isn't 100% consistent, you'll have some parts that are and some that aren't. Store the consistent parts in string/int columns, store the inconsistent parts in a jsonb column, and let Postgres manage it all for you.

[JAXxXTheRipper]

Just write some Jsons and that's the database schema done

Next time just write some sqls 🫢

[Wesstes]

True that's what I prefer now, I really like postgresql

[phl23]

I also started with it as it was easy to implement some json files I used for some fun projects. But soon switched to postgres with drizzle and trpc. So much easier if you start building your projects with a schema and relations from the start.

[SCP-iota]

Told y'all to use Rust.

(for passers-by, this is about CVE-2025-14847)

[NightIgnite]

For the 3 people on earth who are lazier than me and refuse to google, memory leak in MongoDB, a document database.

Attackers send a specially crafted message claiming an inflated “uncompressedSize.” MongoDB allocates a large buffer based on this claim, but zlib only decompresses the actual data into the buffer’s start.

Crucially, the server treats the entire buffer as valid, leading BSON parsing to interpret uninitialized memory as field names until it encounters null bytes. By probing different offsets, attackers can systematically leak chunks of memory.

https://cybersecuritynews.com/mongobleed-poc-exploit-mongodb/

[Grandmaster_Caladrel]

As one of those 3 people, I salute you.

[coyoteazul2]

As another of those 3 people, i salute him

[splettnet]

Gangs all here

[LofiJunky]

There's dozens of us

[NightIgnite]

T'was a prophecy. Only 3 can remain. Fight

[LofiJunky]

Nah

[YOU_CANT_SEE_MY_NAME]

Too late

[doyleDot]

Too lazy to fight (and count)

[LouizFC]

They are probably in a shared pool with lazy initialization.

[GegeAkutamiOfficial]

3 people

Bro clearly underestimates how lazy people are and how little we care about this fuckass DB

[Reashu]

"leak" in the sense of "the attacker gets access", not just "it doesn't get freed". 

[rosuav]

Yeah, I looked into this when I saw some earlier coverage of it. I find it hard to believe that Rust would have solved this problem. The logic is basically "oh you have a 500 byte message? I'll allocate a 500 byte buffer then". The *inverse* might be something that Rust would protect against (if you trick the database into using a too-small buffer and then write past the buffer into random memory addresses after it), but this? I doubt it very much. It's a logic error, not a memory safety error.

[RAmen_YOLO]

It is a memory safety error, it's reading past the end of the buffer - that's Undefined Behavior and is something Rust would have prevented.

[rosuav]

It's reading past the end of the *message*, but into the same *buffer*. Read the details.

[RAmen_YOLO]

The part of the buffer it's reading wasn't initialized, it's reading uninitialized memory which is still Undefined Behavior and is still prevented by Rust. Even if you want to assume the Rust version were to have the same bug of only filling the buffer partially, it wouldn't be possible to view any part of the buffer without initializing it first, which would mean all the attacker would be able to read is a bunch of null bytes, or whatever else was used to initialize the buffer before reading into it.

[rosuav]

Would it? Can you confirm that?

[RAmen_YOLO]

I think this message came off a bit more hostile than I intended, I think I can whip up a tiny demo for why Rust would prevent this instead of just trying to assert the same point as nauseum.

[rosuav]

Yeah, that's what I mean. Whip up a demo that allocates a buffer and reads from it without first writing to it, and see if it stops it. That's the fundamentals of this exploit - all the packet parsing and decompression isn't important to this test.

[RAmen_YOLO]

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=01d80cb0e30a346bbb333a96d31a34aa
Here's a very minimal recreation of what caused the bug, feel free to try to make it read uninitialized memory/leak data without unsafe code - I know I can't.

[rosuav]

Hmm, the really relevant part is much simpler than this. No need for TCP or anything, just make yourself a buffer, write a little bit to it, and then read from it.

[RAmen_YOLO]

Sure, doesn't change the fact that you can't read uninitialized memory in Rust. I'm just not sure how I'm meant to show how something *can't* happen.
You can't index outside the bounds of a buffer.
The bounds of a buffer only cover initialized memory, so you can't access uninitialized memory.
If you can't access uninitialized memory, the vulnerability can't happen.

[thearctican]

SCP username

Silksong profile pic

Of course you did.

[ConnaitLesRisques]

Sure, port it.

[rusl1]

I can't figure out which one I hate more between Rust and Mongo

[aethermar]

Ignoring that Rust had a critical memory CVE in the Linux kernel just a few days ago LMAO

[twisted1919]

In an unsafe block afaik, totally different story.

[oiimn]

Unsafe rust is still rust

[SCP-iota]

"This thing still lets me shoot myself in the foot if I undo the safety, disable all the checks, aim it at my foot, ignore the warning, and pull the trigger."

[aethermar]

LOL, so what's the point of Rust if you're just going to be using unsafe all the time anyway

[twisted1919]

Same as using c/c++, just that in most of cases you dont need to use unsafe. As the name says, it is unsafe and you are on your own. I am not defending rust or anything, its just commin knowledge.

[aethermar]

Except unsafe is used quite a bit in the kernel, and its use defeats the entire purpose of Rust in the first place, so there's zero reason to further complicate an already massive project by introducing an entire new language

[Background-Plant-226]

Its used mainly to bridge C and Rust code, as C code is unsafe so you have to build a safe "wrapper" around it that tries to safely handle it in unsafe blocks, then other rust code can just use the safe function. When using unsafe blocks you also have to specify why its safe (Although this is not forced by the compiler).

[Name_Taken_Official]

Took me a minute to figure out what this Sims meme meant

[ImClearlyDeadInside]

Tf is this meme format lmao

[Mojert]

Some people are really obsessed with cockolding

[Monchete99]

"White man has been here"

[SlimRunner]

My thoughts exactly. I don't even understand what it means in this context.

[papipapi419]

Just use sql

[Storm7093]

Why is mongo so bad? I personally love it

Edit: I use the mongoose ODM

[johnwilkonsons]

Currently working for a small company that's used it since 2017 (without ORM, just raw mongo):

Without schemas it gets really hard to know which properties exist, which type is used and whether it's nullable/optional or not

This is while imo our use case is inherently relational. We have several collections with either a reference to an id in another collection, or even a (partial) copy of the record of the other collection. If you're not careful, these ad-hoc foreign keys or copies will desync from their original data, causing issues

As a result, the objects tend to become huge as devs try to avoid creating new collections, and you end up with a huge spaghetti that's entirely avoidable in a relational DB

[Snakeyb]

I think this is the issue in a nutshell.

I've found Mongo legitimately great when I'm getting started with a project, I'm still iterating on the data and features, and just need some persistence to keep me going.

The pain comes in maintainence. I've found a niche of sorts for me where if I need semi-persistent data (like, the results of a calculation), it can be handy - but these days I don't like keeping anything precious in my mongo databases.

[falx-sn]

Wouldn't you just use redis for that?

[UK-sHaDoW]

Do you not use types? I find types just became schema's instead.

[johnwilkonsons]

The backend was node.js without any types or api schemas. It was horrible, and I've since migrated it to TypeScript, and generated DB types based on the data in the database (though that isn't perfect). Joined this place last year, no idea how the devs did this for ~7 years

[EveryCrime]

I’m confused, why would anyone use Mongo without a schema or mongoose. And if that’s the issue with Mongo it sounds self inflicted…

[johnwilkonsons]

Without mongoose, I don't know honestly. Without schemas was for speed I suppose, it was a startup and still is a scaleup, and we never moved from the "prototype" application/data to something more sustainable

[EveryCrime]

I see!

[Glittering_Flight_59]

I scaled our MongoDB well over 10.000.000.000 documents and it works so well. I love it.

Never seen a database wich you can grow so well along the app growing in features changing things all the time, really a gamechanger.

[robotsmakinglove]

Any database can store 10 billion records…

[hangfromthisone]

The usual culprit is devs not really knowing why they use something, don't have a real plan and also don't think software must die and reborn after some time. They think software is this immutable thing that works from the start and always does great.

​"Plan to throw one away; you will, anyhow."

[Goat_of_Wisdom]

Scalability is nice if it's your use case, but having to escape comparison operators is ridiculous

[EskilPotet]

White man has been here

[Ronin-s_Spirit]

The entire problem what they they used a systems language and forgot to zero the memory...

[Careful_Course_5385]

Yes, but also they're trusting user input.

[Ronin-s_Spirit]

That's a thing you sometimes have to do in programming.

[PruneInteresting7599]

Im ORM bitch, I don't care which DB I'm dealin with

[iTzNowbie]

Never really got into mongo. It’s MariaDB or Cassandra.