I get what you mean, but to me that's the same as saying "I'm not a HTTP guy, I'm a web guy".

I mean, sure, he may be a "node guy", but he uses node to make web applications. A large part of that is persistence, i.e databases. For a lot of applications it's one of the most important part of your stack, if not the most important part. It's your treasure trove, it's your crown jewels. Your app is just a thing that shuffles state around in the database.

He knew a fair bit about NoSQL databases, but why did he not even consider a relational one? I'm not trying to single this specific guy out, merely asking what people think is causing the trend of engineers over-using non-rel databases for relational data.

Edit: didn't see your edit. you're spot on.

I spend a lot of time, as a consultant, talking to people who've already made technical decisions that are biting them in the ass and it seems to mostly boil down to good press and an impressive of the five-minute demo. The mental effort required to learn new stuff is scary and always looks worse than it really is; easy demos hook novice and many-years-a-novice developers to the point where, well, of course it seems obvious not to use RDBMSes, they're hard and you might have to spend time on learning them and you might even look silly or dumb (gasp!) when you're doing it.

From the outside, Postgres looks hard. It isn't hard, but it looks it, because it was not designed around a five-minute demo. I use it for everything until I have a very compelling reason not to. But I have an established library of scripts and systems to make it easy, because I am both an infrastructure guy and a software developer so the idea of "I'm going to write a Vagrantfile in two minutes flat and drop in this provisioner" is something that's top-of-mind for me. (Or I just steal the Vagrantfile from another project, whatever.) But I've made that investment and it's paying off--if one hasn't made that investment, it's scary And then doing it in production? Whether it's a hosted service like RDS or doing it yourself, you have to answer a lot of capital-Q Questions along the way and that's effort that seems unrelated to actually getting your software done.

It's not just "why didn't this person think about a RDBMS?". It's that all of these easy-answer-but-not-really systems (fill in your own) are capturing the minds of developers. The quest for abstractions and ways to make ourselves better able to do our jobs is a good one. The uncritical adoption of tools that might not actually do that is not, but that's a cultural thing not limited to datastores.

Same here. We have several clients who got moved to Postgres from a randomly selected unfit technology. Funny thing is with things like Solr you can build a really fast search index as well on the top of doing ACID transactions in the db. This covers almost every aspect of data engineering. There is obviously the scaling limit with Postgres but most of our clients are in the single db instance range by the size of their data.

Yup yup. Our consistent advice to clients:

- By the time you reach the limits of a Postgres setup, you will either be making so much money that porting it is a couch-cushions deal or your company is a smoking crater in a hillside.

- SPAs are fine. SPAs plus server rendering is often a pain in the rear. Walk, then run.

- If you can't express concretely why you want a container fleet, you don't want a container fleet. Your cloud provider's autoscaling will suffice. (This advice is different for non-cloud clients, but the overhead of leaving space in a container fleet for new deploys or for scaling is deadweight and turning around a container in thirty seconds is probably not as important as the blogs you read tell you it is.)

> If you can't express concretely why you want a container fleet, you don't want a container fleet.

I think this applies to most relatively new (hype cycle) technologies.

It does, but relatively few of those technologies have the desperate money being shoveled into their marketing in the way that containers in particular (and non-RDBMS datastores, to a lesser extent) have. So those tend to get called out explicitly because no, unless you are profoundly out of the ordinary, you don't need a hot new Kubernetes cluster on day one.

Exactly. I have seen this container hype exploding in recent years. A quick example: I worked for a stratup who spends ~60% of their AWS budget of operating Kubernetes and roughly ~40% on their own services. I asked their chief IT guy why is that and he could not justify it with anything other than Kubernetes is cool.

This radiates truth. I would like to read more of the things you write.

I certainly drop enough stuff around here. But maybe I should get back into blogging. ;)

Although my business partner and I have talked about a "fundamentals of cloud system design" course on Udemy or something...