> Consider using just a normal database—personally for me that would be Firestore (Google-hosted) or MongoDB (basically self-hotsed), because I strongly prefer scalable NoSQL databases.
And then goes on to say:
> But for most people, it's probably going to literally just be Postgres. You don't need more than Postgres.
Those statements are basically contradictory. Maybe the author only works on applications where NoSQL is a good fit. Otherwise, it's not clear how the author is different from "most people".
This idea that SQL databases are not "scalable" has become a meme and is difficult to eradicate. Sure, sharding/replicating Postgres (if you need to) can be more difficult than just increasing a field in some auto-scaling group. But a well-tuned Postgres can service a ridiculous number of requests. If you are doing microservices, then it's even better, since you'll have multiple smaller databases - some of these can even be NoSQL if it fits the application.
What 'scalable' NoSQL databases usually means is that you can just throw money at the problem and increase the number of instances, without spending time doing silly things like 'optimizing' queries.
Of course, for some applications, NoSQL is a perfect fit. But far too often I see people reaching out to NoSQL based on some future (usually unspecified) "scale" needs. Heck, I've even seen that mindset in internal, corporate network only apps.
And then goes on to say:
> But for most people, it's probably going to literally just be Postgres. You don't need more than Postgres.
Those statements are basically contradictory. Maybe the author only works on applications where NoSQL is a good fit. Otherwise, it's not clear how the author is different from "most people".
This idea that SQL databases are not "scalable" has become a meme and is difficult to eradicate. Sure, sharding/replicating Postgres (if you need to) can be more difficult than just increasing a field in some auto-scaling group. But a well-tuned Postgres can service a ridiculous number of requests. If you are doing microservices, then it's even better, since you'll have multiple smaller databases - some of these can even be NoSQL if it fits the application.
What 'scalable' NoSQL databases usually means is that you can just throw money at the problem and increase the number of instances, without spending time doing silly things like 'optimizing' queries.
Of course, for some applications, NoSQL is a perfect fit. But far too often I see people reaching out to NoSQL based on some future (usually unspecified) "scale" needs. Heck, I've even seen that mindset in internal, corporate network only apps.