Is the hype over yet? I guess it's been dying down over the past 2 years

Is the hype over yet? I guess it's been dying down over the past 2 years

Attached: mongo-db-logo.png (370x185, 23K)

Other urls found in this thread:

dev.to/ankush981/mongodb-has-no-use-case-58ob
github.com/PostgREST/postgrest
unqlite.org/
twitter.com/NSFWRedditGif

Most apis are json.
I dont see it going anytime soon, just because there is no hype for HTML5 doesnt mean is not there.

MongoDB is obsolete now that real databases like Postgresql and SQL Server have rich JSON storage support. Anything MongoDB can do, these other databases can do too, usually faster than MongoDB as well.

Yep, it's over. Products are abandoning it after the license change.

>propietary shit
Ayy lmao.

Mongodb is still solid and improving with every version. The fact that aws is stealing their outdated api should tell you something

>Postgresql
>propietary

>Most apis are json.
Most APIs are JSON, but most of these APIs use SQL as their database, because their data model is still normalized. We want to handle that normalization in the storage and retrieval of the data itself using SQL features like JOIN, rather than forcing the consumer of the API to join the data together by hand. The alternative to doing JOINS at the database level is usually that the consumer has to do a select n + 1 type of retrieval, i.e. if you have an auto parts store, and you want to get which parts are in stock there, you'd have to load a document for that store, which would have an array of product ids, then you'd have to loop over that array and look up each product by id one at a time. Or, get the list of every possibly product, loop over it, and filter out the ones not in the array. With a SQL backend, you can do a join in your retrieval an end up with an array of product objects instead of an array of ids.

totally irrelevant bullshit, JSON has nothing to do with databases, also almost all communication between services is done via grpc these days,

>json has nothing to do with databases

Attached: 1511796055019.png (245x206, 6K)

stop using your photos in Jow Forums

...Yes he's right retard. JSON is an interface. You can parse the data however you like before ever touching JSON.

Not like you'd know that mobile """ dev""" being either not-white or being addicted to drugs since age 12.

Attached: image0-23.jpg (720x842, 97K)

It doesn't, it's just descriptive syntax like XML.

Ya'll guys are retarded and have no clue what you are talking about.
Look up horizontal vs vertical scaling. JSONB in postgres is just as fine for '''unstructured''' data as a NoSQL DB, but the latter scales way better.
Not that any of you tutorial following pajeets would ever touch real scale, but still.

C# nigger detected.
If you need to store data from a bunch of apis storing the json would be much easier.

any 4 yo kid knows that json in postgres is unstructured and that nosql scales horizontally better, retard

>JSON
>storage

you can't have an IQ higher than 60, you're not even worth the time to argue with, if a database stores data as json, it means it is designed by an illiterate nigger with no degree like you

>any 4 yo kid knows that json in postgres is unstructured and that nosql scales horizontally better, retard

I guess the posts in this thread must have been made by 3 year olds then, hence my point
>MongoDB is obsolete now that real databases like Postgresql and SQL Server have rich JSON storage support
>almost all communication between services is done via grpc these days
There also seems to be major confusion about what JSON actually is, kek.
Just stay with Python and JS frontend shit please, we can't have bootcamp 'engineers' fiddling with databases.

json is for pussies

t. bootcamp student with no real degree

Not an argument.

t. arrogant low IQ retard


MongoDB is unquestionably easier to use and more dev friendly than RDBMS, it's theoretically easier to scale, but if you ever dealt with """scale""" as you claim you will understand that MongoDB is cancerous at large scales when it comes to data integrity and always inferior when it comes to performance and complex exaggeration/relationship queries

tldr; you are a low IQ who want to sound high IQ but instead embarrass himself with every additional comment

>MongoDB is unquestionably easier to use and more dev friendly than RDBMS
stopped reading right there
try using databases beyond 'build an epic vue/express/mongoDB app' tutorial. unstructured data is awful to work with at a certain point, meanwhile even non-programmers can get into SQL easily.

please read the whole comment to understand my point, low IQ nigger

what about Couchbase?

This.
99% of data has some kind of relations. Using MongoDB means you will have to spend hours implementing something that normal database archive with just few constraints. And you will mostly likely fuck things up.

if it's really the case then graph databases would BTFO both document nosql like mongo and relational like postgres

You know you can just use SQL syntax in mongo right.

>implies mongo is easy to learn just following tutorials
>"b-but SQL is FAR EASIER AND BETTER"

Are you Indian?

no, but you are unless you tell me what's wrong in what I said

dev.to/ankush981/mongodb-has-no-use-case-58ob

>Ankush Thakur
>INTP
Stopped reading there

>whimsical INTP programmer
Gaaaaaaaaaay
Also fuck off pajeet

Their stock price isn't dying.

it is, you are a dumb piece of shit. JSON is a tree structure format, to pass data around.

your API will return a projection over your db, which could be:
- raw data
- aggregated data
- any of above + enriched
- ...

As you can see stored data has nothing to do with what API can or should return.

data storage format will directly represent your business domain problem and use case

It's not about being able to execute an SQL query, its about the DB being organized to allow complicated to be executed efficiently. Once you relax the constraints on your data, you weaken that capacity.

>mongoloid
What a terrible name. Why ever use this instead of Mysql(or MariaDB) and Postresql

JSON is a data container,
>using json as ur database

ew

Those who used MongoDB because of JSON never had a clue about what they were doing in the first place. MongoDB's real selling point is horizontal scaling. It's real replacement is coming in the form of FoundationDB on one side (transactional horizontally scalable dumb storage made by very smart people with SQLite levels of reliability testing) and CockroachDB on the other (an actual open source RDBMS built for horizontal scaling).

That's debatable. Unless you are drowning in joins, graph edges are not necessarily a better abstraction. Graph databases also tend to have performance problems when looking for data ranges and there isn't a good mature open source one on the market. Neo4j has given them a bad rep. Dgraph is still a babby.

>JSONB in postgres is just as fine for '''unstructured'''
Even better is a JSON API over normal rows.
github.com/PostgREST/postgrest

>horizontal scaling
Completely unnecessary until your application reaches massive scale, which it won't because you spent all that time fucking around with RetardDB instead of using a real database.

Horizonal scaling is a meme. You can vertically scale a RDBMS to retarded scale, then cache your entities via HTTP at the CDN layer, and if thats not enough you can encorporate sharding. Most absolutely huge scale systems use SQL, not mongo, and the ones that don't use SQL don't use mongo either and often aren't as mission critical as well

actually if you're a company that really need """scale""" you can just pay for managed SQL databased on AWS, Google Cloud, Azure, etc... and they will horizontally scale automatically for you among other things like automatic backups


preferring mongo for scaling is a marketing meme

You'll notice that I wasn't making an argument in favor of using MongoDB for anything. CockroachDB is the most promising database built with horizontal scaling in mind. If you actually need horizontal scaling on a budget, running CockroachDB on directly on hardware (for example, at OVH) is more attractive than a managed database. AWS ain't cheap.

Another nice thing about CockroachDB is that you get replication "for free". No need to set up replicas and failover.

>You can vertically scale a RDBMS to retarded scale
Although this is true, scaling vertically to a retarded scale costs a lot. Horizontal scaling becomes cheaper long before you hit the point of "retarded". There are types of businesses that store a lot of hot data and need to think about scaling from early on. They're the primary targets for sharding and horizontal scaling.

unqlite.org/

it gets worse, you launch it with
>mongod
makes me shiver every time I type it

>With a SQL backend, you can do a join in your retrieval an end up with an array of product objects instead of an array of ids.
(not true, by the way)

mysql has shit specifically for handling json data though

JSON is shit tho,
why even use tree/hierarchical data structures?
>hurr I want my queries to be in O(n^2) instead of O(n)
just use CSV