Mongo can’t stop winning (I hate it)

Great Pods

Mongo can’t stop winning (I hate it)

Key Points

MongoDB's stock jumped 40% in the last day and a half, reaching a $24 billion market cap (about half the size of Ford)
Revenue increased 24% year-over-year, with Atlas revenue up 29% (representing 74% of total revenue)
MongoDB is a document-oriented NoSQL database that stores data in BSON (binary JSON format) with flexible, self-describing documents
Main advantage is flexibility - no strict schema requirements, making it easier to handle changing data structures without migrations
Scales well as a document store because it's easier to shard and distribute compared to relational databases with complex joins
MongoDB is particularly useful for "vibe coding" and AI applications where data structure may be unpredictable or evolving
The company has a strong sales team that targets large enterprises rather than individual developers
MongoDB changed from open source to Server Side Public License, causing conflicts with Linux Foundation and other tech companies
AWS, Microsoft, and Google are uniting behind Linux Foundation's DocumentDB to compete with MongoDB's vendor lock-in
Added only 2,800 customers (5% growth) but revenue grew 29%, suggesting existing customers are paying significantly more
Atlas (MongoDB's cloud hosting service) handles the complexity of setup and deployment that makes self-hosting difficult
Document databases are becoming more important for AI applications dealing with semi-structured data like chats and context
MongoDB doesn't have traditional database relations, making it simpler but less powerful for complex data relationships
The company is positioned more as a sales enterprise than a developer-focused technology company
MongoDB sued the Linux Foundation over licensing issues, making it reportedly the only database company to sue Linux
The database is particularly suitable for applications that need to scale indefinitely without complex schema management
Increased usage is likely driven by AI tools and "vibe coding" applications that generate more data operations
While criticized by many developers, MongoDB serves a specific niche for rapid prototyping and applications with unpredictable data structures

Full Transcript

Language: en
If you've been around for a while, you
know there are few things I like to talk
about less than MongoDB. And believe me,
I don't want to talk about it today. But
this happened. Uh yeah, Mongo's stock
jumped 40% the last day and a half.
Their market cap's now $24 billion.
[&nbsp;__&nbsp;] is now a$ 24 billion company. For
reference, that puts them at about half
the size of Ford. Yeah. Two mongos now
equals one of the biggest car company in
the world by actual ship vehicles. I
have feelings.
We have a lot to talk about here because
uh on one hand this shouldn't have
happened but on the other hand it was
kind of inevitable. There's a lot of
reasons why [&nbsp;__&nbsp;] is being valued very
highly and the important ones are their
revenue. Their revenue went up 24%
year-over-year. Their Atlas revenue in
particular went up 29% which is 74% of
their total revenue. And they added
2,800 customers which is not that big of
a number until you understand how
Mongo's platform works. I have a lot to
talk about here from a really awkward
experience I had with the [&nbsp;__&nbsp;] team not
long ago to the reason why they're
actually getting customers and why
people are choosing [&nbsp;__&nbsp;] in the first
place to uh go and I feel sick even
saying this part. Uh the the the
benefits of [&nbsp;__&nbsp;]
God, sorry.
Little I I'm feeling a little sick. It's
not going to be a fun one for me, but uh
yeah, I don't own stock in [&nbsp;__&nbsp;] I have
equity in a lot of their competitors,
which means I'm in a lot of pain right
now. Just roll the sponsor. We'll get
back to it in a sec. Not going to lie,
it kind of sucks hiring right now. There
are so many people applying to every
role and they're filling their resumes
with these padded blobs of AI text. just
parsing through it to try and find a
good candidate is nearly impossible,
especially if you don't know what
exactly you're looking for just yet or
how long you're going to need them for.
Hiring's gotten chaotic, and you could
go hire a bunch of recruiters that don't
actually understand tech to try and help
you find good employees. Or you can use
today's sponsor, G2I. They're the only
company that help you get good engineers
fast without compromising on quality at
all. They really get it. I've been
hanging with these guys forever. They
host my favorite React comp, React
Miami, and there are I I don't even know
how to put it. They just really
understand this. I referred a few of my
startup friends over to G2I and all I
have heard is the most positive stuff
about how unbelievably good the
candidates they find are. It's their
goal to go from interview to first poll
request merged in a week. And I've seen
them pull this off many times. It's not
marketing fluff. They can actually do
it. And the coolest part about this is
how flexible the people you hire can be.
You need a senior engineer for a few
weeks to rebuild your mobile app, you
can get that. If you need a couple of
junior engineers to help you long term,
you could find them. If you need a
really senior person to come in for six
months to help you rearchitect your
entire infrastructure as you figure out
what's going on long term, you can get
that. Whatever you need in person,
remote, US, Europe, iOS, Android,
Python, AI, whatever, they have you
covered with their 8,000 experienced
engineers. And these aren't people
looking for their first gig. These are
experienced people that they keep
around, ready to go for opportunities
like your company. If you're ready to
hire faster and better, check them out
now at soyv.link/g2i.
So, let's get started with uh why the
[&nbsp;__&nbsp;] is everyone using [&nbsp;__&nbsp;]
first in case you all don't know what is
[&nbsp;__&nbsp;] Other than a mistake, it is an
alternative document database. I don't
have the heart to explain this myself.
So, I will pay an AI to do it for me
using GBD5 mini on low because uh [&nbsp;__&nbsp;]
is a low IQ choice.
God, I hate this. Also, 5 Mini is an
underrated model. MongoDB is a
distributed documentoriented NoSQL
database that stores data in BSON which
is a binary JSON format. Each record is
a flexible self-describing document kind
of like JSON which can contain nested
objects and arrays. Main comparison I
wanted to make was Dynamo DB which is
the really powerful document data space.
It's technically a KV but it is used as
document store. There's also Amazon
document DB which I never actually heard
anyone using. They just use Dynamo. The
way I've described [&nbsp;__&nbsp;] in the past is
Dynamo for babies. Actually though, it's
worse than that. It's uh databases for
babies. Schemas are hard. The DB wait,
but it actually scales a bit. The DB,
it's a lot of things. The big thing with
[&nbsp;__&nbsp;] compared to SQL or other real
databases is that it's a document store,
which means that the shape of a given
element is not predetermined by the
database itself. If you have a table in
SQL, it has columns that are specific
values. So a user table will have a
name, it will have a created at, they'll
have an updated at, have an ID, might
have an email, might have a lot of other
things, profile, pick, URL. You get the
idea. When you have a table, in most
databases, the table has columns that
describe the things that a given row in
that table will have in it. A user
collection in [&nbsp;__&nbsp;] will have a JSON
blob. They're doing their own custom
JSON [&nbsp;__&nbsp;] and you can do really cool
stuff with it, like index on keys and
whatnot. But the point I'm trying to
make here is that the elements, like the
core entities in [&nbsp;__&nbsp;] are really
flexible. And historically, that hasn't
been super valuable because it's not
that hard to change the schema in a
database. Obviously, migrations [&nbsp;__&nbsp;]
suck. I've complained about that
forever. And we've also been seeing more
and more funny things recently like
people using AI agents like I don't know
replet was a funny one and it makes
changes to the database. It tries to
migrate those changes. It can't because
there's a field that's mandatory that
wasn't before. Like if we had a bunch of
users in the user table and we didn't
have propek URL and we add it as a
mandatory field. What happens to all the
rows that don't have that yet? It's a
great question. In the case of Replet,
it didn't want to deal with it, so it
just nuked the table. Yes, Replet was
willing to just nuke an entire database
like an actual prod because it couldn't
migrate the changes because it had a
mandatory field that wasn't mandatory
before. It was a whole drama a few weeks
ago. [&nbsp;__&nbsp;] doesn't have these problems
because [&nbsp;__&nbsp;] doesn't have structure.
[&nbsp;__&nbsp;] has data in a vague sense. It just
has these JSON blobs floating around.
This obviously has a lot of negatives.
When you get a user from [&nbsp;__&nbsp;] you
don't know what you're getting. It
should be the shape that you usually
use, but it's possible you have things
that were written before that shape was
being enforced that are just floating
around. You can do a lot to manage that
and try to maintain reliable schemas
within [&nbsp;__&nbsp;] The likelihood that you're
actually doing that as a [&nbsp;__&nbsp;] user
varies wildly. But that flexibility is
actually quite useful when you don't
know the shape of your data yet or you
need to just shard it and scale it
indefinitely. When you don't have to
make sure the specific shape of the data
is persisted, it's literally just a key
value store. It kind of just goes burr.
It's relatively easy to scale when you
don't have complex relations between
things because [&nbsp;__&nbsp;] doesn't really have
relations. kind of has vague concepts
resembling relations that you can use.
But if I have my user table here and
users have messages, I might have
message ids as an array on here. But
more likely what I have is I have a
separate message table and the message
table has an author ID. And now I can do
a join between the message table and the
user table to get the messages for a
given user. that lets you in one query
get the user and all of their data as
well as the messages that are linked to
it. Now, let's say we want to scale this
database. We have to shard it and break
it up across many nodes. What happens if
multiple of this user's messages are on
multiple different nodes? Well, that
query's performance just went to [&nbsp;__&nbsp;]
In [&nbsp;__&nbsp;] everything's just kind of
sharted by default. Well, depending on
how you set it up, obviously. And since
[&nbsp;__&nbsp;] is obnoxious to actually set up
and deploy, it is not uncommon for
people to just give up and go to the
MongoDB company and use Atlas, which is
their cloud host for [&nbsp;__&nbsp;] They handle
all of those things for you, similar
like what Planet Scale does to your SQL
database, but you don't have to worry as
much because [&nbsp;__&nbsp;] I want to say it's
slow no matter what, but it's
performance is fine. It handles these
things decently well. So, the benefits
of [&nbsp;__&nbsp;] oh god, I hate that statement.
God, I hate this. I hate having to do
this part so much, but uh first off,
that it's very flexible. no strict
schema. It scales well because it's a
document store, so it's much easier to
shard and break up. You'll still have
the problem of if the messages get split
up across different things. Joining and
collecting them all can be annoying
because you have to get the user, get
their ID, then search for all messages
that match this index. Thankfully, it's
smart enough that you can have an index
be a shard key. So, you can have all of
the messages indexed on a given author,
go to the same place so that they can
all come up from the same spot.
Insert web scale joke here.
MongoDB handles web scale. You turn it
on and it scales right up.
Uh, what else? Really good sales team.
The sales team's really good at their
jobs. They've convinced a lot of
companies that aren't very technical to
move everything over to [&nbsp;__&nbsp;] I'll say
it's much easier to use than Dynamo. The
only real competitor for [&nbsp;__&nbsp;] is
DynamoB because DynamoB was built from
the ground up to be a document store
that scales really well. [&nbsp;__&nbsp;] was built
to be a database in a web era. Another
alternative way of thinking of [&nbsp;__&nbsp;] is
that it was the first web database and
their branding was the first webcale
database. What it actually was was the
realization that more and more
developers don't want this strictness in
their SQL and they want something that
feels more like an API that they're
hitting that will just give them the
data that they put there. Also, every
other SQL dialect was invented before
JSON. [&nbsp;__&nbsp;] was invented because of
JSON. And that's how we ended up with
the classics like the mean stack which
was [&nbsp;__&nbsp;] express angular and node as
well as m stack which uh you can do the
This was a whole era and a lot of this
was because [&nbsp;__&nbsp;] suddenly meant you
don't have to understand SQL really well
to make a database that works. Anyone
can make a database that doesn't work
now. Yeah. Anyways, I promised an
awkward story about [&nbsp;__&nbsp;] I want to
tell it. So, I was at a random I I don't
want to be too specific about people and
the space, but I really want to
emphasize this like sales team part
because I think it's funny. So, this
might sound a little arrogant and I'm
not trying to toot my own horn here.
I've just been wanting to tell the story
for a while and I'm thankful to have the
opportunity. I was at a random developer
event, AI focused event that [&nbsp;__&nbsp;]
happened to be a big sponsor of. They
had a huge booth. I was walking by said
booth with a friend of mine. my friend
notices somebody that they recognize at
[&nbsp;__&nbsp;] and like says hi quick and they
come over put out their hand they're
like oh who are you good to meet you
totally fine I don't expect every person
at every dev company to know me I don't
expect many of people to know me
honestly especially outside of SF that
said 70% of developers who use AI watch
my videos it's a it's a crazy stat that
I still can't believe but when I go to
like a Y combinator event or I go to a
bar in the city I I see that in real
life there's a lot of people recognize
me by the way if you do see me at
something and you want to get a photo,
don't feel bad. Feel free to ask. I
don't care. It's fine. Like meeting my
fans and seeing them in person. It's
cool. I'm not complaining. It's It's
weird, but it is really cool. It's a
little more annoying when I leave my
apartment and get recognized down the
street when I'm trying to like go grab
food, but it's fine. I get it. There's
something specific about what I'm doing
out here, and it's another word that
makes me feel sick. God, I hate typing
this. Devrell.
Sorry, stomach's not feeling great after
that one. For better or worse, you could
categorize what I do as developer
relations. A lot of what I do is relate
to developers, show them things that I
find interesting and cool, and talk
about dev [&nbsp;__&nbsp;] I've kind of had impact
on the Devril space. There's a lot of
people who were doing YouTube videos
that no longer are, and instead are
working to get people like me to cover
their stuff. There's been a lot of
change in the Devril space that I
think's been really good overall.
Developer relations being a person at a
company that doesn't code that makes
crappy blog posts about AI [&nbsp;__&nbsp;] is not a
good thing. But a developer relations
expert at a company whose role is to
figure out where developers go to get
information, what information is and
isn't missing, and to try and plug the
gaps and find ways to position the
company's product in the right circles
or the right devs and the right devs in
general. That's a good dev. Someone like
Lee Robb for example made this
transition well where previously he was
the guy doing content for Verscell like
had a YouTube channel where he covered
them multiple times a week and moved
away from that when I started doing well
so that he could make content that would
help my content and work with people
like me directly instead. Devril has
shifted significantly over the years and
a lot of that is because of the
influencers like Primogen like WebDev
Cody like Mickey like Typcraft like
myself we've shifted oh Josh coding is a
really good example as well. There's a
lot of examples of these new developers,
Bash Bunny as well, who have changed
what developer media looks like. I think
it's fair to say that someone employed
in Devril should probably know who most
of those people are. At the very least,
if you're a Devril targeting early to
mid-stage companies, trying to get them
to adopt different database
technologies, you should probably know
who Prime and I are. Just statistically
speaking, like if it's your job to get
developers to pay attention to your
thing and you don't know who developers
in that space pay attention to, you're
not very good at that job. Similarly, if
you're a like experienced React
developer that like on your resume,
senior React engineer, you know what
React Query is? I question your
expertise. The reason we've went down
this absurd rabbit hole is a story I
want to tell about when I was having
this awkward conversation at the [&nbsp;__&nbsp;]
booth because this person who's being
awkward with me already puts out their
hand and says, "Oh, I'm X. Who are you?"
And I laugh, assuming it's a joke. Not
because I think everyone should know who
I am, but just was an awkward
interaction. Then I said, "Oh, wait. Oh,
yeah. I'm Theo. I'm a dev YouTuber. I
talk about a lot of full stack database
stuff to early to mid-stage startups.
Thought you might know who I was. My
bad. Uh, what do you do at [&nbsp;__&nbsp;] Oh,
I'm a Devril and head of media at [&nbsp;__&nbsp;]
I didn't take this personally. I just
laugh. Thought it was funny. It's like,
oh yeah, it makes sense. The the head of
media and devril at [&nbsp;__&nbsp;] wouldn't know
who I am. Yeah, that that checks out.
Just thought it was funny. It's like
[&nbsp;__&nbsp;] doesn't really get what devs need
anymore. They're a sales company. That's
fine. It is what it is. Apparently, this
absolutely crushed the person who I had
that awkward experience with. And later
on when I was walking out to go home, an
exec at the [&nbsp;__&nbsp;] booth pulls me over.
It's like, "Hi, can we talk?" Sits me
down at the corner. Like they have a
giant [&nbsp;__&nbsp;] booth and like there's a
little table hidden in the corner and
they sit me down with my channel manager
and have the most awkward [&nbsp;__&nbsp;]
lecture slash investigation experience
I've ever had at any event like this
trying to mitigate the likelihood I tell
this story but instead made me feel so
incredibly [&nbsp;__&nbsp;] awkward. like the
worst I felt around anyone at any of
these companies ever that I'm dedicating
an unreal amount of time in this video
to talking about this because that
awkwardness, that level of
uncomfortable, the fact that he was
trying to both figure out what had
happened but also make me feel bad for
it shows the level of both
incompetence and fundamental lack of
understanding of the dev space that
exists within [&nbsp;__&nbsp;]
This is a sales enterprise that happens
to have a technology at the core of it.
It's not a database company. It's a
sales enterprise company that just so
happens to pretend to be a database and
technologies company still. And being
that that's what they are, it makes all
the sense in the world that the new
Devril media person had no idea who I
was because actually a good analogy from
chat smells like Oracle. If this was an
Oracle booth, I would expect the exact
same thing. It's still funny to me, but
it is what it is. This means that we're
not the target. The target's big corpse.
Absolutely. The thing that was funny
here wasn't, oh, they don't recognize me
because I'm so famous. It's they don't
recognize the developer ecosystem
because they're not selling to
developers. They're selling to these
giant enterprises. And that's why I made
a joke about it. It's like, oh yeah, you
guys wouldn't know what developers like,
huh? And they took it really personally
because that's [&nbsp;__&nbsp;] They're more
likely to complain that people think
they don't understand devs than they are
to put in the footwork to understand
devs. And I ended up getting cornered by
a [&nbsp;__&nbsp;] exec because of this. That's
the [&nbsp;__&nbsp;] experience in a nutshell.
But if you're a Fortune 500 that is vibe
coding some [&nbsp;__&nbsp;] and wants a database
that will theoretically scale and not
require migrations, you probably already
have a contract with [&nbsp;__&nbsp;] so you're
just adding another line to it. This is
actually the thing I think benefits
[&nbsp;__&nbsp;] a lot right now because it is so
flexible. It's actually decent for vibe
coding. All the problems we see with
like the replet agent where it nukes the
table cuz it can't migrate. That's not
going to happen in [&nbsp;__&nbsp;] If one of
these random vibecoded apps you [&nbsp;__&nbsp;] out
actually starts getting a lot of
traffic, you just go pay Atlas more
money. It actually makes sense as a
database solution for things that you
shouldn't be building in the first place
but are being built. Also, funniest
tweet possibly like of the year so far.
Sam for Planet Scale. Trump put a tariff
on joins.
God, this is the difference between like
Planet Scale and [&nbsp;__&nbsp;] Both are selling
to enterprises, but Planet Scale has a
deep understanding of the developer
ecosystem. [&nbsp;__&nbsp;] barely knows what
developers are. Different worlds, like
entirely different worlds. I think it's
fair to say that [&nbsp;__&nbsp;] doesn't really
get devs. In fact, [&nbsp;__&nbsp;] sued the Linux
Foundation because they changed the
license for MongoDB to be the serverside
public license, which means that the
built-in [&nbsp;__&nbsp;] adapters in Linux were no
longer legal. They sued them for it.
Yes, [&nbsp;__&nbsp;] is, as far as I know, the
only database to sue Linux. Yeah.
Thankfully, Microsoft has come out as
the decent player in the space. And now
document DB from Microsoft is a stable
open source project that happens to have
a [&nbsp;__&nbsp;] adapter that works that it can
now be brought into the Linux
Foundation. So yes, [&nbsp;__&nbsp;] is the only
company that is so evil and so
fundamentally doesn't understand
developers that Microsoft had to come in
to help Linux out because of [&nbsp;__&nbsp;]
Yeah, I think I've made my point.
Mongo's weird vibes. AWS, Microsoft, and
Google unite behind Linux Foundation,
Document, DB Database to cut enterprise
costs and limit vendor lockin. This is
all because all of these companies are
pissed that [&nbsp;__&nbsp;] went from open source
to rug pulling and now basically force
you to use Atlas. This is kind of what
Reddus did where they rug pulled, but
Mongo's much more aggressive with it.
You basically can't use [&nbsp;__&nbsp;] in the
cloud reliably unless you're using
Atlas. combination of their crazy
licensing and the fact that it's really
hard to host [&nbsp;__&nbsp;] or properly.
document databases are important for AI
apps for tasks such as chats, context,
and memory.
AI apps are all about semi-structured
data and document databases are
purpose-built for it, said Carrill,
who's the vice president Microsoft and
document DB's primary architect. He's
not the he's a vice president at
Microsoft. But there's no open- source
standard engine for document databases
like what Postgress is for relational.
Yeah, [&nbsp;__&nbsp;] was supposed to be, but they
chose to make more money instead.
Clearly, it's working. They're [&nbsp;__&nbsp;]
printing. But uh yeah, now they are
being competed with with AWS, Microsoft,
Google, and Linux Foundation. Very
similar to what happened with Reddus,
but even more aggressively. Yeah. And
this happened yesterday right as they
announced their revenue. So you can see
why this back and forth is happening
because [&nbsp;__&nbsp;] doesn't care about
developers. They care about their bottom
line which is enterprises paying them
too much money for hosting JSON blobs.
Yeah, enough about the weird vibes. We
need to talk about the benefits of [&nbsp;__&nbsp;]
a little bit more. God, I hate that
statement so much.
I'm suffering. I do kind of see the
value of [&nbsp;__&nbsp;] for weird vibe coding
side projects. That hurts. I hate saying
it. I just personally was building an
app using codecs and it chose to use
SQLite and ran into a decent number of
problems that resulted in it making a
global type that assigned the return
type to the API that we were hitting to
get the SQLite data. It also had to run
a migration and hope that that went
right. And if I made changes, it could
potentially break things. [&nbsp;__&nbsp;] could be
a good enough solution for those things.
If it wasn't obnoxious to set up, but if
you're already on Atlas, you're already
on Atlas.
God. So, my honest assumption is that
the reason this is happening, the reason
[&nbsp;__&nbsp;] is making more money and getting
more customers is that there's more need
for these vibecoded type things. And if
you ignore every interesting database
change that's happened in the last 5
years, [&nbsp;__&nbsp;] is seemingly a very good
solution for this. There's a whole list
of technologies that I think went from
useless to quite viable due to AI and
vibe coding. Like workers on Cloudflare,
for example, the world's most fancy
switch statement. Cloudflare workers are
great if you want to turn a URL into a
different URL. They're not good if you
want to do something harder like render
HTML because they're not fast. They're
really small, low power isolates on top
of V8 in random places around the world.
But if you're literally just passing
data from one place to another, they're
really good cost-effective solution. So
if your code can be boiled down to a
switch statement, platform workers make
a lot of sense. But if you're doing
anything more complex, not so much so.
Do you know what else is a glorified
switch statement? Every single API doing
inference. If you are on T3 chat and you
are generating a response, we're not
running the info generating the
response. we're hitting an API for
OpenAI or Claude or anything else. And
most of the time, our server is getting
those responses. It's kind of just
sitting there. It's waiting for the next
token to come from OpenAI and then just
forwards it straight down to you. It is
barely using any compute during this
time. As such, traditional serverless
platforms or even traditional servers
didn't make a lot of sense for this
workload because the amount of usage and
the amount of CPU the computer's using
for this is relatively varied and low.
Cloudflare workers make a ton of sense
for that and all of a sudden workers
became by far the most cost-effective
way to do scalable inference across
different providers. Similar happened to
Convex where the idea of having your
entire configuration and infrastructure
as a folder in your codebase went from
oh that'd be nice but I don't want to
give up the modularity to holy [&nbsp;__&nbsp;] I
need this right now so AI agents can
actually change my code. It's really
cool. [&nbsp;__&nbsp;] by not having a schema or
really much of a reliable system beyond
the scaling side makes a lot of sense
for this too. [&nbsp;__&nbsp;] very well could be
one of the better choices for vibe
coding. I know some very smart people
that have strong opinions on databases
that don't like [&nbsp;__&nbsp;] but pick it for
this. Like uh a fun one, I don't know if
he'll care if I say this, but I'm going
to. uh Jared Palmer from Verscell who
made Turbo repo. He was saying that he's
surprised he doesn't see way more people
using [&nbsp;__&nbsp;] for their vibe coding apps
because not having to figure out the
schema ahead of time and just writing
the data than reading it and erroring if
it doesn't match your validator is a lot
easier to just get something up and
running. I don't disagree and apparently
they're growing a lot because of that.
There are more and more people who are
picking [&nbsp;__&nbsp;] for their use. That said,
the much more interesting piece here,
29% year-over-year growth, but they
added 2800 customers. So, they had a 5%
growth in customers and a 30% growth in
revenue. How did revenue grow six times
more than new customers did? That's a
great question, and they've not
necessarily been transparent about the
answer. Let's see if they have it here.
Seems like almost all of their revenue
is still subscriptions, which means that
the subscription costs had to go up
because once again, they only added 5%
customers, which means that all of their
existing customers are now paying more
money. The average customer would have
had to have their cost go up by about 20
to 25% for these numbers to happen.
which means either they are just ramping
up prices, which could be the case, but
more likely a handful of their customers
are doing way more input and output on
[&nbsp;__&nbsp;] and on Atlas. So, they had to ramp
up their subscription tier and now
they're making more money off of those
users because some of those users are
vibe coders. Yeah, this is my theory
that internally a lot of these companies
are letting more people do things to
their data pipe where like the analytics
team can now have a vibe coding tool to
make new dashboards and collect new
data. And now the amount of I/IO that a
random team that doesn't even have devs
on it is doing at various companies that
are on [&nbsp;__&nbsp;] is going up. That's why I
think [&nbsp;__&nbsp;] is making more money. They
are charging their existing users more
because a lot of them are probably using
it more and a lot of that's probably
because they're using AI to do things
that involve generating more data and
requesting more data thereby increasing
the amount of usage the [&nbsp;__&nbsp;] databases
that they have provisioned are getting
resulting in more money being spent.
I still wouldn't use it but if you want
to I guess I understand what a company
I'm not talking about [&nbsp;__&nbsp;] anymore. I'm
gonna go now.

← All Summaries

Watch on YouTube