Postgres has nowhere near all the features of redis. Go and have a look at the redis command’s documentation. They’re not even really similar at all, once you get past basic GET/SET stuff.
I feel like one could implement most Redis commands as functions or PL/SQL using native Postgres hstore and json. Could be an interesting translation layer.
Well, you can't do O(1) part for most commands :) redis can do a lot of stuff at near constant (and superfast) speed. Databases do become slower when your dataset is big
You can buy servers with 1TB RAM for reasonable price. Also, you don't need to go this big, even moderate-sized tables are slow. Indexes are usually log(n) at best (and eating more RAM anyway, you can get said log(n) if all index data is in memory, and at this point regular sql db eating more ram than redis), and insert time is slowing down since you need to update index as well (and maybe reorg stuff around)
This is silly, Postgres doesn’t speak the Redis wire protocol. You will need a large army of connection proxies to get a Postgres database to handle the number of connections a single Redis shrugs off with no sweat.
Maybe you like this answer more: At the end of the day you can embed a bunch of Turing-complete programming languages in Postgres, and Postgres can store binary blobs, so Postgres can do literally anything. Can it do it performantly, and for low cost? Probably not. But if you put in enough time and money I’m sure you can re-implement Redis on Postgres using BLOB column alone.
No, that's a completely different thing - an index access method, building a bloom filter on multiple columns of a single row. Which means a query then can have an equality condition on any of the columns.
That being said, building a bloom/cuckoo filter as a data type would be quite trivial - a basic version might take an hour or two, the more advanced stuff (to support partial aggregates etc) might take a bit more. Ultimately, this is not that different from what postgresql-hll does.
