Skip to content
unnudged
brandCooling

MongoDB on X

MongoDB talk is steady rather than dying: as many people post about using it happily as name it when a question comes up, and more push back on the "slow" or "dead" knock than are down on it. PostgreSQL is the comparison alternatives posts keep making.

First written 27 Oct · what changed · from 89 posts by 82 people

Tracking posts that say “mongodb”

Track this for your market
Posts, last 24h
41
0%vs. previous 24h
Posts, last 7 days
371
155 in the last 72h
Velocity
53/day
7-day average
Momentum
−23%
Last 24h vs. a normal day this week

Posts per day, last 30 days

as of Nov 3, 11:01 UTC
2001000Oct 20: 38 postsOct 20Oct 21: 30 postsOct 22: 65 postsOct 23: 33 postsOct 24: 46 postsOct 25: 0 postsOct 26: 0 postsOct 26Oct 27: 113 postsOct 28: 41 postsOct 29: 28 postsOct 30: 34 postsOct 31: 49 postsNov 1: 69 postsNov 2: 44 postsNov 2

What changed

as of 27 Oct · checked once a month

First written 27 Oct. When what people say changes, it shows here.

Tone· 41 posts from 39 people· written 27 Oct

How do people feel about MongoDB?

Reception is level at the top: as many people post about using MongoDB happily as name it when a database question comes up. More people defend it against the "slow" and "dead" knock than are down on it.

The two largest groups are level: 13 people post about using MongoDB in their own work and 13 name it when someone asks what database to use. The first group's posts are build logs — Mongoose pre-save hooks for password hashing, aggregation stages for daily revenue, a Todo API migrated to Atlas, indexing to cut query latency — and one calls themselves "a MongoDB person" because it was the first database they learned. The second group often answers with one word, "Mongodb", and rarely says why; one gives "flexibility" as the reason.

Behind them, 7 people push back on the idea that MongoDB is slow or finished, blaming schema design ("mongodb isn't slow. your schema is"), crediting indexes and BSON serialisation, and pointing to a business that has lasted. 5 are down on it: one wants to quit it, one found no reason to use it in a data science career, and one calls a ledger-service migration the wrong choice.

  • Uses it happily14
  • Recommends it when asked13
  • Defends it against the knock7
  • Down on MongoDB5
  • Using it for now2
See 5 of 41 posts

I'm a MongoDB person. It was the first database I learned, so it'll always feel like home. 😄 Relational DBs fit rigid, structured data. MongoDB fits flexible, evolving data. Not switching, just more open to learning relational now. #MongoDB #SQL

5 of the 41 posts behind this answer, one per person. The other 36, and every new one as it’s posted, come with tracking. Get early access

Pain points· 22 posts from 21 people· written 27 Oct

What do people complain about with MongoDB?

No single complaint leads: Atlas setup and admin friction and security holes are each named by 5 people, and slow-at-scale is level on 5 posts with 4 people. What goes wrong is spread across operations, breaches and query design rather than one sore point.

Complaints come in three similar-sized bundles. Atlas setup and admin is named by 5 people: a connection configuration that blocked a Flask app, DNS and TLS debugging between Render and a cluster, a migration that stalled on unhelpful support, an email to update a cluster idle for a month, and a 4.5 TB database being migrated away to save about $700 a month.

Security is named by 5: NoSQL injection payloads that slip past a login by testing for fields that are not null, misconfigured instances open on the internet that get hit "minutes of being on the internet", a university breach involving an open MongoDB, and a warning that an integration node left credentials in its error data.

Slow at scale is level on posts: offset pagination walking thousands of documents to return one page, a query fast in development and slow at 10 million orders, a missing index, sharded balancer settings. 3 say it was the wrong tool for relational data; 2 report outages; 2 cite docs and tooling that don't line up.

  • Atlas setup and admin friction5
  • Security holes5
  • Slow at scale5
  • Wrong fit for relational data3
  • Outages2
  • Docs and tooling don't line up2
See 5 of 22 posts

Last night, I ran into a frustrating bug while working on my Flask application. My app couldn't connect to MongoDB. 😩 The problem? My database connection configuration wasn't working correctly. I approached it by checking my MongoDB connection string, verifying my database

Proactive white-hat agents that strike and patch before the bad guys can. A similar thing I have seen with misconfigured mongodb instances that are open on the internet, they get hit minutes of being on the internet.

Bug Bounty Tip: NoSQL Injection via Payload Fuzzing Look for: Login forms and API endpoints accepting JSON like {"username":"x","password":"y"} Test payload: {"username":{"$ne":null},"password":{"$ne":null}} If it bypasses authentication, it may indicate NoSQL Injection, enabling auth bypass or data extraction from MongoDB. For more tips join our Telegram channel: link #BugBounty #NoSQLi #PayloadFuzzing #InfoSec

5 of the 22 posts behind this answer, one per person. The other 17, and every new one as it’s posted, come with tracking. Get early access

Alternatives· 19 posts from 18 people· written 27 Oct

What are the alternatives to MongoDB?

PostgreSQL is the comparison almost everyone makes: 15 of the 18 people here weigh MongoDB against it, usually in PostgreSQL's favour. MySQL, Supabase and plain document storage get a mention each.

The section is close to a single comparison. 15 people weigh MongoDB against PostgreSQL. The most common argument is that PostgreSQL's JSONB already covers the document case while keeping joins, ACID transactions, foreign keys and no licensing question — "Why add MongoDB when you don't need it?" Some split the two by data: Postgres for "structured data like user_id", MongoDB for "unstructured data like user preferences". A few report acting on it, migrating projects from MongoDB to Postgres on a VPS, or calling PostgreSQL "miles ahead" for backends and MongoDB "a bit of a memory hog". One counters that MongoDB's value has narrowed rather than gone, since Atlas revenue continues.

The rest is thin. 2 people bring up MySQL, one warning not to write it off and one asking whether either can store images. 1 post cites a survey of 1,245 makers' products where Supabase appeared far more often than MongoDB. 1 chose ordinary document storage over MongoDB Vector Search because embeddings were complexity they didn't need.

  • PostgreSQL15
  • MySQL2
  • Supabase1
  • Plain document storage1
See 5 of 19 posts

body tire me small, I migrated couple of my project db from MongoDB to Postgres on my VPS today, and have to do the same migration for Cloudinary to my self hosting storage, got a lot to complete this weekend

mongodb is definitely not dead (Atlas does over $2B in ARR), but the 2016 "MERN stack for every web app" hype is completely dead. here are the three architectural reasons developers moved away: 1. PostgreSQL JSONB killed its core value prop: in 2014, devs picked Mongo because relational SQL couldn't handle flexible documents. then Postgres added JSONB with GIN indexing. now you can query nested JSON fields with index scans AND keep foreign keys, ACID transactions, and relational joins in the exact same database. 2. the "schemaless" production trap: "schemaless" in the database just means you pushed schema validation into application code (Mongoose/Zod). after 3 years of product iterations, you have 5 different document versions coexisting in the same collection. migrating millions of polymorphic BSON documents without ALTER TABLE DDL is an operational nightmare. 3. relational reality: 95% of web apps are relational: users -> workspaces -> orders -> line items. modeling this in Mongo forces you into two bad options: - embedding: hitting the 16MB BSON limit and suffering unbounded array mutations. - referencing: using $lookup (which is literally just a slower, unoptimized SQL JOIN). where Mongo actually dominates today: gaming player profiles/inventories, IoT time-series, and e-commerce catalogs with hundreds of polymorphic product attributes. for standard SaaS, PostgreSQL won the war.

5 of the 19 posts behind this answer, one per person. The other 14, and every new one as it’s posted, come with tracking. Get early access

Questions· 9 posts· written 27 Oct

What do people ask about MongoDB?

The most-asked question is whether MongoDB can do a specific job — store images, run on a VPS, handle two bids at once — from 4 people. Next is the choice against PostgreSQL, from 3.

The largest group of questions is capability, 4 people asking whether or how MongoDB handles a task: whether MySQL and MongoDB can store images, whether MongoDB can be deployed on a VPS, whether an auction wallet should use MongoDB transactions or atomic updates so two bids landing at once can't overspend, and how Atlas deals with "data inertia".

3 people ask the database-choice question directly — which to use for a SaaS, and, more pointedly, "Give me one reason to choose PostgreSQL over MongoDB" and the mirror, "When would you choose MongoDB over PostgreSQL?" with a request for one real-world case where it wins.

2 ask what MongoDB is for at all: one asks whether it is dead and why nobody uses it, another asks why a founder picked it for churn loops and what they learned. A question to the brand itself asks whether Atlas provisioning shows region, size, network exposure and cost before approval.

  • Can it do this?4
  • MongoDB or PostgreSQL?3
  • Why use MongoDB at all?2
See 5 of 9 posts

5 of the 9 posts behind this answer, one per person. The other 4, and every new one as it’s posted, come with tracking. Get early access

Wishes· 3 posts· written 27 Oct

What do people want from MongoDB?

Three people each want one thing fixed, and they don't overlap: a provisioning preview before a cluster is created, docs examples that work together, and an export another system can rebuild from.

This is the thinnest section on the page: 3 people, one want each, so no wish carries more weight than another.

The first asks whether Atlas cluster provisioning shows region, size, network exposure and estimated ongoing cost in its approval preview, arguing a natural-language "create the database" summary "can hide quite a lot".

The second is a docs fix: the examples switch between users, words and cases collections, so a document inserted as Alice never appears in the following find query — using db.users throughout would make them work together.

The third is about leaving: portability needs a restore test rather than a shared API, so that a different runtime can reconstruct the same facts, provenance, expiry and access policy from an export and explain anything missing.

  • Show details before provisioning1
  • Fix the docs examples1
  • Prove data portability1
See the 3 posts

For cluster provisioning, does the approval preview show region, size, network exposure and estimated ongoing cost? Those are the decisions a person needs to review; a natural-language “create the database” summary can hide quite a lot.

Portability needs a restore test, not just a common remember()/recall() API. Can a different runtime reconstruct the same facts, provenance, expiry, and access policy from an export—then explain any omissions? #DataPortability

In their words

How do people talk about MongoDB?

The phrases people use most, counted once per person.

  1. 1“complex joins”3
  2. 2“relational joins”2
  3. 3“flexible data structures”2
  4. 4“faster schema changes”2
  5. 5“access patterns”2
  6. 6“definitely not dead”2
  7. 7“remove mongodb”2
  8. 8“saas postgresql”2

Posts are shown the way X shows them. One of them yours? Here’s why it’s shown, and how to take it off.

Also in Serverless databases

Get every post about MongoDB, filtered and labelled

This page is the summary. Tracking gives you the stream behind it for any brand, keyword or @mention: each new pain point, request and question as it’s posted, with the spam and promotions already taken out.