Do you need separate systems when you already have Postgres?

Is there something specific you wanted to do that was prohibited by a license. I thought most of the licenses you’re talking about just prohibited you from reselling the database as a service.

I love Postgres, and I agree with the general sentiment. But I read the (growing) genre of "use Postgres for everything" articles and they imply a difficulty in running other software that I just don't see.

I'm thinking of Redis in particular. If you're using it as incredibly fast but not critical storage, it's trivial to set up and it ~never crashes or requires maintenance. It creates no headaches, and in exchange gives me a k/v store that I can thrash without worrying about performance (I know it's fast), downstream impact (am I slowing down critical-path SQL queries), etc. Especially in the age of LLMs, which I've found to be great at devops-type tasks, I feel slightly less compelled to simplify my stack.

I'd love the ability to mark a table as "read committed" to prevent long running transactions from keeping old versions of a tuple alive, or even "read uncommitted" to enable in-place updates. Or perhaps instead of downgrading isolation, those serializable/snapshot transactions could simply fail when reading a value from such a table that was modified after they started.

An example of a table that would benefit from this would be rate-limits / concurrency-limits, which are commonly implemented using Redis instead of Postgres.

I am very much in camp “minimize your dependencies and take the utmost advantage of what you already have” but I also am in camp “your database is the most important bottleneck component.”

This has two implications:

1) make sure if you use Postgres for anything beyond core rdbms functionality that there is no dependency between the two, so you can rip out the additional functionality and move to a different platform when you end up needing to reduce the load on your db server

2) if using Postgres for non-essentials complicates your db backup workflow, risks the data integrity, makes it difficult to maintain or upgrade your Postgres instance (eg you have to wait months or years for compatibility with newer Postgres versions), or loads relatively shoddy or unstable code into the beating heart of your application, then you should either use a different Postgres server/install/container for these ancillary services or bite the bullet and introduce an alternative dependency, depending on which makes more sense.

Surely the last place you'd want to use those weaker consistency guarantees is a concurrency limiter?