this post was submitted on 27 Jun 2023
2 points (100.0% liked)

/kbin meta

63 readers
1 users here now

Magazine dedicated to discussions about the kbin itself. Provide feedback, ask questions, suggest improvements, and engage in conversations related to the platform organization, policies, features, and community dynamics. ---- * Roadmap 2023 * m/kbinDevlog * m/kbinDesign

founded 2 years ago
2
Kbin and NoSQL (kbin.social)
submitted 2 years ago by [email protected] to c/[email protected]
6 comments fedilink hide all child comments
 

Hi there ! (First post ever yay!)

I’m, like a lot of users lately, been migrating from Reddit to Kbin and Lemmy.

I finally had a good reason to contribute by writting HelmCharts to run Lemmy and Kbin on Kubernetes ( hopefully some of you might be interested !)

Anyways, i was wondering whrn analysing the docker stack of Kbin if instead of running postgresql, it could be replaced by a NoSQL service such as MongoDB.

I felt like the concept of the fediverse and the data structure seem pretty compatible.

And since there have been some performance issues ( probably for database) lately, it might be an interesting way to deal with large volumes of data.

Let me know what you think !

Cheers!

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 2 years ago (1 children)

I think there's quite a bit to say about cost. I'm not sure how Mongo is, but I'm quite familiar with DynamoDB and it gets quite expensive at scale. I'd be worried it'd be unsustainable, especially since postgres is very cheap most of the time (aka, unless you go with RDS).

Also, I'm sure Postgres can be optimized to work well at kbin's scale (since it has worked on sites with millions of users for years). I'm hesitant to say it's an issue with postgres itself, it may be an issue with the queries to the database (maybe the lock?) or even with database auto-scaling (or possible lack thereof).

Also, kbin's general data seems to be highly relational - articles will always have an author, a title, how many votes it has, how many boosts, and all of the comments on it. I think (personally) SQL makes more sense than NoSQL here for that reason, among the others I've listed.

[–] [email protected] 2 points 2 years ago

A very interesting take ! They might have been a way to structure the data, but indeed it might make more sense to use a relational DB.

Thanks for the answer ^^