Dear Stephan, in my experience (6 years as tech evangelist for AWS, met with thousands of startups and large companies in 6 continents - not to brag, just to give you context, AWS' success and relevance is only very slightly attributable to my tiny contribution), what you suggest might work if and only if the company is not really successful, and its IT needs do not change quickly over time.
If instead we're talking about a fast growing startup, a single solution like Postgres (btw, I adore Postgres, to be clear), it's going to become an issue.
You can dramatically improve your performance if you allow the use of Redis, as a start. And your title could have been "Just use Postgres + Redis for everything", and it would have been half as bad, or quite good.
I think it's ok to try to keep things simple, but limiting yourself to JUST Postgres is not going to work.
> might work if and only if the company is not really successful
What is your definition of success? I’ve seen Postgres scale to pretty large loads. I’ve also seen plenty of complex stacks where the scale never warranted the complexity.
That said, Redis + Postgres is a pretty simple stack, so I’m not complaining about your suggestion. I’m more curious about specifics.
I have seen postgres queries being answerd in low ms range.
Why would I want to use redis ?
Only if my loadtest suggest that postgres is a bottleneck and redis is faster.
Keep complexity down to min to make it functionally work.
Loadtest and fix the bottlenecks.
add complexity when you know the gain.
If instead we're talking about a fast growing startup, a single solution like Postgres (btw, I adore Postgres, to be clear), it's going to become an issue.
You can dramatically improve your performance if you allow the use of Redis, as a start. And your title could have been "Just use Postgres + Redis for everything", and it would have been half as bad, or quite good.
I think it's ok to try to keep things simple, but limiting yourself to JUST Postgres is not going to work.