Disclaimer: I work at Asana We have an in house system (LunaDb) which is a little like this. There's a tech talk available about how it works at https://blog.a

Disclaimer: I work at Asana We have an in house system (LunaDb) which is a little like this. There's a tech talk available about how it works at https://blog.asana.com/2015/10/asana-tech-talk-reactive-queries/ https://blog.asana.com/2015/10/asana-tech-talk-reactive-quer... - it's from a few years ago, but the core ideas are there. There's also some details on the caching layer we built for it at https://blog.asana.com/2020/09/worldstore-distributed-caching-reactivity-part-1/ https://blog.asana.com/2020/09/worldstore-distributed-cachin... A few properties based on your questions and the observations here: - We don't attempt to incrementally update query results. Given the number of simultaneous queries the system handles, we've found it much more important to instead by very precise about only re-running exactly the right queries in response to data modification. - We support joins (although not queries of arbitrary complexity). We avoid a race conditions and cross-table locking issues by using the binlog as our source of changes, which imposes a linearization on the changes matching the state in the db. Correctly determining which queries to update for these requires going back to the database. - Performance is an interesting problem. It's easy to arrange situations where total load is a function of "rate of data change" * "number of queries over that data", so being overly broad in triggering recalculations gets expensive fast. We're actively hiring to work on this - if you are interested my contact details are in my hn profile.