What in-memory database supports triggers to the outside world to wait on?

Question

Database

Actually, the requirements are:

1. To be in-memory.

2. To support triggers in general . Everything seems to be simple here. Yes, even Tarantool.

3. So that triggers can be interrogated from the outside . That is, if not all drivers (client libraries), but some of them must support these triggers. So that the microservice using this database can hang a callback on some table - and it would be called when data is added to the table.
And with this point, hard hemorrhoids already begin. The same Tarantool - there are triggers, but for some driver to forward them outside, I found absolutely nothing, except for one issue to one of the drivers, where the developer answers that the connection in the library is implemented according to the session principle and therefore the triggers are out are not supported and never will be.

4. And not just poll from the outside, but so that you can wait ala await when the trigger fires. Suppose we have a certain queue in the database, which is sometimes replenished. And in the microservice there is a route that is polled by the client according to the principle of HTTP long polling. The client makes a request, the route hangs the trigger... and waitsawait'ohm until the trigger fires. And how it works - returns data to the client, and clears the queue. And then the client makes a request again and everything repeats.

In my opinion, this is a completely logical idea, and it’s even strange how this in-memory database in 2021 may not have this.

However, in the same vaunted Tarantool, I did not find anything better for this situation, except to stupidly poll the queue selectevery N * 100 ms. Despite the fact that the triggers themselves are in the database.

Answer 1

If my memory serves me, Apache Ignite had something like that.