I haven't seen people often refer to the stack in the site as a "microservices architecture": databases, key-value stores, message queues, object stores and other specialized solutions are typically viewed in a category of their own, orthogonal to what the application architecture is, unless you'd have for example 3 different PostgreSQL instances for the same project.

From what I've seen, even if you'd have PostgreSQL, Redis, Garage (S3) and RabbitMQ, that might still be considered a monolith if you just have a singular deployment unit for your app (even if scaled to multiple instances). It'd still be a distributed system, sure, much the same way how an app that's connected to a singular DB is (just fewer points of failure), you'd just be separating the concerns across specialized solutions.

Aside from that, you can get pretty far with just PostgreSQL alone, but sometimes it's nice to have the more specialized solutions because the libraries and APIs that they have are optimized for working within a particular domain - for example, object storage easily letting you handle file uploads, downloads, Range requests, presigned URLs and so on, so you don't have to build anything yourself or think that much about what would be the best way to store a bunch of binary data in a RDBMS.

On the flip side, if you can somehow avoid the pain of trying to put everything in PostgreSQL, the idea of having a single source of truth for all of the concerns in your app is pretty darn nice! Might as well take a step further and get rid of the front-end/back-end altogether and make the DB serve web requests (or use an embedded DB within your app process), but that gets dangerously close to the mess that was Oracle Forms or that is Oracle ADF.