I’m the administrator of kbin.life, a general purpose/tech orientated kbin instance.
I never understood why people compare nosql to rdbms. They are entirely different systems with different use cases.
Where you neee data consistency and need to always get the same results to a query go with a structured rdbms. Where you need speed over all of that (and there are real use cases for this) then nosql is for you. Using both is of course a likely result too.
There’s of course a lot of other considerations. But they’re different tools for different situations.
Just do it really quickly!
Wait, that’s my key. Ohhh QIDBA not QADBX.
OK, the cynic in me thinks that isn’t a vibe coder typing that, but someone in middle/upper management. They’ve recently fired most of their engineering teams and replaced them with (probably externally contracted at a considerably lower rate) vibe coders.
They’re recognizing some of the problems that were highlighted when this trend started to gain traction and are now thinking of a way where they don’t need to accept being wrong in their actions, but also somehow still profit from it by only using real engineers (probably also on external contracts with shitty conditions) when it’s absolutely required.
Maybe I’m wrong.
I do use postgres but only as an rdb provider. I thought while it supports json data as a type, does it provide for all of the other advantages of nosql databases for their use case?
Ultimately I feel like the best solution is to have a single database provider that could do both fully. I’m not sure it’s really there yet. But halpt to be told I’m wrong. I’ve not really needed that myself for my projects.