My interpretation of "Postgres for everything", which I totally agree with, is that it is a sane initial default for just about anything. It is a well-understood stack that most people have had some exposure to, and that can handle quite a wide variety of problems. New/specialized tech will have all sorts of sharp edges, it will absolutely introduce complexity, and bring about headaches you didn't expect. And frankly, in lots of cases it's premature optimization. With all that said, if the use case has proven itself out and Postgres is truly starting to struggle - by all means, good time to explore alternatives. There are no silver bullets in this business.
‘Every app is properly a db app’ is Oracle’s defining mantra and they weren’t the first.
Their sales reps LOVE the Postgres For Everything movement. It realigns app arch debates to traditional structures, conventions and objection handling.
Once a target account has made a tech commitment to PG4E, it is a trivial matter for sales to walk in later, have a ‘business conversation’, and the next thing you know your boss signed a seven-year Oracle deal.
Simply speaking "Postgres for everything" is meant as a fool-proof default choice for the average person making an average app. It helps startups avoid tangling themselves with some bespoke/complex combination of Redis+Postgres+RabbitMQ+MongoDB from day 1 for their app that reaches a peak of 10 requests per second with 100 daily average users if they are lucky.
This usually happens because a junior dev wants to have fun and pad their resume while playing around with tech. Or they are insecure and want to make the "maximally proper" choice with everything so they appear to be an expert. For example they think storing any JSON or cache data in Postgres is somehow incorrect or forbidden and they must use something more specific to feel like they've made the correct choice.
In general Postgres will take people very far. Majority of companies could start with it and live with it forever. If they are lucky enough to need something else by that point hopefully they have enough money and staff to re-evaluate the stack and make changes for the future of the company.
My interpretation of "Postgres for everything", which I totally agree with, is that it is a sane initial default for just about anything. It is a well-understood stack that most people have had some exposure to, and that can handle quite a wide variety of problems. New/specialized tech will have all sorts of sharp edges, it will absolutely introduce complexity, and bring about headaches you didn't expect. And frankly, in lots of cases it's premature optimization. With all that said, if the use case has proven itself out and Postgres is truly starting to struggle - by all means, good time to explore alternatives. There are no silver bullets in this business.
‘Every app is properly a db app’ is Oracle’s defining mantra and they weren’t the first.
Their sales reps LOVE the Postgres For Everything movement. It realigns app arch debates to traditional structures, conventions and objection handling.
Once a target account has made a tech commitment to PG4E, it is a trivial matter for sales to walk in later, have a ‘business conversation’, and the next thing you know your boss signed a seven-year Oracle deal.
Because you worked at Citus and Clickhouse, I think you are more experienced than most of us.
But I can add that saving medium to large files in PostgreSQL, or clickhouse, doesn’t work well.
Simply speaking "Postgres for everything" is meant as a fool-proof default choice for the average person making an average app. It helps startups avoid tangling themselves with some bespoke/complex combination of Redis+Postgres+RabbitMQ+MongoDB from day 1 for their app that reaches a peak of 10 requests per second with 100 daily average users if they are lucky.
This usually happens because a junior dev wants to have fun and pad their resume while playing around with tech. Or they are insecure and want to make the "maximally proper" choice with everything so they appear to be an expert. For example they think storing any JSON or cache data in Postgres is somehow incorrect or forbidden and they must use something more specific to feel like they've made the correct choice.
In general Postgres will take people very far. Majority of companies could start with it and live with it forever. If they are lucky enough to need something else by that point hopefully they have enough money and staff to re-evaluate the stack and make changes for the future of the company.
postgres is great but seems too high level "for everything."