Boring technology is so crucial. As a private sector startup company you are already living a fraught existence - why risk it even more with unproven tech?
As an example, mongodb inexplicably became a de facto DB for a bit between 2013 and 2016. It seemed like 1/3 of startup companies switched from MySQL or Postgres to Mongodb. What an absolute unmitigated shitshow clusterfuck moronic disaster
Literally every client I've had in the past months uses MongoDB, even though their data is relational.
I can't imagine why would someone choose mongo in that case except to be slightly faster in the first few days of development, since you don't have to create a schema and update it. The problem is that you pay back that initial advantage with a lot of interests once your data becomes more complex and you need stuff like BI.
Anyway, even if your data isn't relational, JSON in postgres still works better than mongo.
Just want to put it here: relational data is not a matter of someone's view, there's theory and science behind it. In fact, there's more than 40 years of theory:
The problem is that nowadays universities are not teaching relational algebra as part of the software Engineering courses. And thus students dont grasp the reasons why relational databases are how they are.
Exactly and the reason I asked is usually when you hear this perspective it's a misconception of what the relational model is -- eg the link you shared describes an internal relationship within the table that is described first and foremost -- this is distinct from what the poster above and many others believe it is when they talk in terms of jargon of related tables "like users, post, and comments" and assume that's what the relational data model is.
"My data is relational" is generally a misunderstanding of the terms
Data with multiple entities that have a relationship between each other. Take a website that has users, posts and comments, for example. Users have many posts and many comments, posts have many comments and one user.
Got it: I consider different objects or entities stored, indexed, and queried separately but with references to each other in the form of identifiers to really just be sound design. Relational data models typically come with more constraints that inhibit classes or online data mutations and scalability choices. I think it's easy to conflate multiple sets of tradeoffs.
The deepest question is whether it's useful to be able to model the world with first class structure in the form of embedded arrays and embedded sub structures that can be richly indexed. Does this involve certain forms of denormalization? Sure but do tables really represent how you think about the world?
> Sure but do tables really represent how you think about the world?
It's not about "how you think about the world", but how you intend to use this data.
Following my previous example, if you're building a blog you know you'll need to show a post along with its author, or that you'll need to filter posts by author, or maybe show only comments by verified users, etc.
Of course you can also structure your data this way on mongo, since over time they've added tools to support it, but it still feels like a feature tacked onto it rather than something "native" as it is with SQL.
Now, I understand what you're saying about my concept of relational being just a form of design and not inherent to the data itself. That's interesting indeed and I haven't thought about it this way before.
Think about an author for a moment: do you want to model all authors with the same set of columns? Might there be a different set of attributes for a current events journalist and a short story writer? Would you not want to describe certain author attributes in terms of lists of attributes and enable filtering/querying on these easily? This is what a flexible/heterogeneous model with first class support for embedded documents and arrays gives you.
I always struggle to think of you would ever want NoSQL to represent data. The benefit of NoSQL is... lack of schemas? Why would you want this except with unstructured user-generated content (which then will need to be structured later to be useful)?
I think there are may be some misconceptions here. There's always a schema. It's about flexibility and heterogeneity of the schema shape and evolution over time
Yes I can change a RDBMS schema over time quite easily. I'm being honest - why is a NoSQL DB better for general purposes? I am a longtime CTO and I have yet to figure this out.
In an RDBMS a schema change is both an application tier change and database tier data definition change and depending on what you want to optimize for that can be a material difference in terms of agility. Anything can be described as "quite easily" but in a fundamental sense if a change requires you to reason and initiate at two layers and that change often requires downtime, you have a major impediment on your hands. You might also call slowing down a feature. I think it's a bit like fiat vs Crypto, there's a religious ferver aspect that drives some people to declare a position on this and a set of tradeoffs aspect.
Yep. Chasing shiny new tech can cause a company to focus on learning the tech with all its early stage issues rather than focus on solving the problems the business faces.
Some new tech fades away. Some is here to stay.
SQL was the shiny thing near the start of my career. I pushed my company hard to abandon network databases in favor of SQL and that worked out quite well.
Same with object-oriented programming over classic C.
Some tech never lives up to its promise and becomes an albatross for its adopters.
There was a time when it was too early to responsibly incorporate LLM technology. There will soon be a time when the board will ask why you didn't. (Maybe for external use cases, certainly for internal ones).
One challenge for CTOs is making the call on new tech. When is boring tech the best thing for the company, when is it acceptable to introduce early stage tech, and when is new tech such an accelerator that you must adopt it?
NoSQL in general is a niche tech. Data is inherently relational. It is very hard for me to imagine a situation where basing everything on Dynamo or Mongo is the correct move, vs. only using NoSQL in specific problems that make sense. Dynamo and mongo generally smell of developers enamoured with specific tools over solving problems efficiently.
As an example, mongodb inexplicably became a de facto DB for a bit between 2013 and 2016. It seemed like 1/3 of startup companies switched from MySQL or Postgres to Mongodb. What an absolute unmitigated shitshow clusterfuck moronic disaster