So who build an hackernews room for fun ?

Maybe you need a query engine and not a parser.

Shameless promotion of my beta engine

https://github.com/V0ldek/rsonpath

If you have an infra that need to scale so much then Postgresql isn't the right tool indeed. The right tools for your use case probably doesn't even exists and you will have to build one.

It is not a mystery why all webscale companies endup designing their own DB technology.

That being said, most of the DB in the wild are not remotely at those scale. I have seen my share of Postgresql/ElasticSearch combo to handle below TB data and just collapsing because of the overeng of administrating two DB in one app.

you can certainly encode queue in many ways. mkfifo just work. But integrating the queue in the DB isn't a bad idea if you want to have both the queue and the db in a shared state.

I am happy that my queue inherit ACID properties.

SQLite simply doesn't allow concurrent write so it is a no go for a queue.

I don't know much about SQL Server and MySQL but I wouldn't favor a lockin closed source software or anything remotely connected to Oracle.

At the end, only Postgresql remains I guess. Also, Postgresql is super solid and the closest to SQL standard.

>>I don't know much about SQL Server and MySQL but I wouldn't favor a lockin closed source software or anything remotely connected to Oracle.

If that's a concern, then MariaDB is another alternative. Postgres isn't the only option in town.

EDIT: I'm correcting myself here because as far as I can tell, LISTEN NOTIFY equivalent capabilities are only available in MariaDB's SkyQL fully managed services offering, and not in the base MariaDB Community Server.

> mkfifo just work

Are you certain about that?

You’re wrong that I’m wrong.

I would say that the biggest missing features is not being able to mix normal and delta tables.

This would allow easier reporting within a very active db without too much bother.

You're right. We're working on this currently. You can track the issue here: https://github.com/paradedb/paradedb/issues/717

It is the same notion exactly actually.

The code isn't magically solving NP vs P but it does simulate non deterministic run through a potentially exponential exploration.

I would argue that it is an already classical idea in the 70s. Non determinism is nothing new.

The cool stuff here is the simplicity of the interface to it and its integration thanks to high order functional constructs (decorator).

Yes, the cool thing here is just to use higher order to provides the user non-determinism seaminglessly within Python while in prolog this is a built in feature.