Who needs MongoDB when you have JSONB?
Who needs MongoDB when you have JSONB?
Who needs MongoDB when you have JSONB?
Yes that's right, it goes into postgres.
“You know what ELSE everybody likes? Postgres! Have you ever met a person, you say, ‘Let’s use some Postgres,’ they say, ‘Hell no, I don’t like Postgres’? Postgres is perfect!”
Yeah! Postgres is great!
MariaDB
Let's schedule a meet-up at 00/00 year 0000 to talk about it.
elephant walks in
Yeah, but is it web scale?
With SQL you scale it when it is required by sharding, read replicas, cache layers, and denormalization.
With NoSQL afaik, we have to deal with the scaling from the beginning by keeping the consistency of denormalized data, that has additional code overhead. Is mongoDB different in this regard?
EDIT: I got whooshed. Thanks for the reference :)
edit edit: Holt shit how did I miss this for 15 years. This is great, stayed accurate all this time.
Shoutout to software that had to deal with y2k and is still popular, gotta be one of my favourite genders.
It’s a reference to this masterpiece: https://youtu.be/b2F-DItXtZs
Just fyi you're taking a meme seriously
who needs any of that when you have microsoft access
There is actually an open source alternative for that in the Libreoffice suite called "Base"
I have used libre office base and found it's buggy mess.
I sugest to use dbbever for any DB, it's different but at least it's not a buggy mess. Or pgAdmin for Postgresql. Or DB Browser for SQLite
Is it actually any good for small personal projects? Just want someone who has used it to answer as I’m considering putting some work into it.
Ow, my integrity
Just use Mongo, it scales so well!
Never understood why anyone chose Mongo. Though I have some funny memories getting rid of it because it was slowing the app down sooo much.
If you need something for storing JSONs and querying, just use ElasticSearch/OpenSearch.
Oh god, all the people storing massive JSON documents, and then having to lock the whole thing to modify sub-entities.
But is Elasticsearch web scale?
I say this with all appropriate irony: as the guy that deployed it at for Wikipedia, yes.
Or add a column next to the json with some data about the json and index that.
I've used it for one small project and quite liked it. I struggle with the concepts behind relational databases and Mongo's approach was understandable for me.
Where I work we use mongo, it's not what I would've picked but i guess it helped early dev speed and bad practices like having productus do direct db edits to save a situation because the app isn't mature yet.
By now when collections are getting huge and documents as well we've had to archive more and more recent data, which causes problems, and we have to really make sure our queries are sharp or cost and lag will go through the roof.
With that said, it actually works pretty ok for a production platform with quite a big customer base, and there are many improvements we could do if we had the time.
If I were there at day one I'd have rooted for sql, mainly based on how much these different collections have to relate, but I don't think mongo is as horrible as many people make it out to be and it does have upsides.
used OpenSearch in a recent project, but the number of annoyances with it are through the roof. From SSL certs setup to bad defaults in settings, and the fact it does type inference for indices requiring you to manually recreate the index, and the docker container that takes 30s to start every time...
If you can use mongo, just use that. Or pick something other than OpenSearch if that's overkill for you.
Yeah, I took one course where we used MongoDB. I was like "still unconvinced, but I'll keep this in mind if I run into situations not covered by PostgreSQL." ...I've not run into situations not covered by PostgreSQL. Everything will be covered by PostgreSQL.
Had to roll my own JSON storage system after spending weeks trying to get sqlite to work on Godot/android.
It took a day and will suck at scale because there are no indexes. It just goes through the whole file, line by line when you search for an id.
BUT IT WORKS.
Hopefully the repos and stuff I piled on top have made it abstract able enough I can move it to a real database if the issue ever gets resolved.
I’m confused about your SQLite troubles … it compiles for pretty much everything - as long as you have a file system mapping.
It's not just me, but seems to affect Godot c# deployments to mobile
https://github.com/godotengine/godot/issues/97859
Worked fine on desktop
Just store the JSON in a sqlite table with an extra column or two for commonly indexed stuff....?
No, you misunderstand. Sqlite just does not work when it's packaged by Godot mono for mobile (see the ticket in the other replies)
It worked fine on desktop which made it more frustrating
I manage instances of both mongo and postgres at work.
I'll say Mongo OpsManager is pretty sweet, and HA is way easier on Mongo.
I really dislike JSonB in Postgres. Just use a ORM at that point.
That's not the point of JSONB. Use normalized tables whenever you can. JSONB allows you to store a document with unknown structure, and it allows you to access that data within SQL.
I probably have just run into a bad example of its use. I can see it being useful for unknown documents.
I run a web app that processes at least one third party JSON document that is so large it would exceed the table column limit if flattened out. It gets stored in a JSONB column. EFCore with Npgsql can query JSON documents in Postgres. Works just fine as long as you put indexes on the fields you're going to be querying.
Ok, I was wrong. The only example I have worked with was just someone being lazy.
I can’t muster any sarcasm out of sheer disappointment. You win this time…
Pros and cons
Jesus Christ, that's JSON Bourne.