Very interesting. My dream is to have something like this, a KV-store, a blob store, and pubsub all behind the same interface.
"like this" meaning you want wire PG compatibility, so you'd do something like this? UPDATE kv SET value = 'alpha' WHERE key = 'beta.charlie'; UPDATE s3 SET value = $b64$good luck$b64$ WHERE key = '/some/s3/path'; LISTEN whatever;
The type of situation I'm thinking about is for example storing a blob in S3, storing metadata and a reference to the blob's path in a database row, sending a message into a queue to trigger some async processing, and updating a cache. It would be nice to be able to do this through a single API or service, and it would be really nice to do all this within some type of transaction abstraction that would allow all operations to pass or fail collectively, really really nice if the whole thing could be pay-as-you and scale horizontally-ish on shared infrastructure without managing nodes or slots or whatever.
I'm not a Postgres user so I don't know how far you can get currently and I should probably look into it in detail. Coordinating blob/ject storage, database, and pubsub operations is a pain point for me presently. I think that overall system design is going to prevent a database-type system from being a good idea for blob storage but I would still like to see someone try to put three systems in a trenchcoat and try to make it work behind one interface.