Sort:  

It's a known issue with hivemind. Hivemind runs two blocks behind hived to avoid microforks, because it doesn't know how to handle fork resolution properly (it never has).

Part of the change we're working on with the hived plugin mentioned above should allow us to enable hivemind to support fork resolution properly, which will allow hivemind to finally serve "real-time" data. This will also be very important for 2nd-layer apps in general.

2x is promising outcome and plus have instant data availability. So, we are gradually moving all social logic to 2nd layer, right?! My only concern was scalability of postgres, if we were to move most social logic to it.

Generally speaking, I've found scalability of postgres to be much better than that of hived for social data. And it's also a much friendlier/safer environment for programmers who aren't aware of all the delicate issues associated with changing hived.

Oh right rocksdb vs postgres of course and I agree, postgresql has wide adoption. But it is bit complicated to scale it, with our current use, it will be ok though. Later replicas and rearranging tables might help...

I did some analysis a couple of weeks ago, and most of the slow down in hived API response time isn't really related to rocksdb itself. The first issue was related to locking, but we improved that a lot already.

In my limited tests, there were usually two remaining causes for slow API call response times: 1) computation of results that could/should have been cached and 2) time to serialize output data (often supplying data that wasn't even strictly needed for most applications).

But the schema changes required to fix some of these issues will be much easier to do in postgresql. And I also see some nice potential benefits with postgresql having built-in interpreters (more about that later).