By "reactive" I mean... if the data changes, the UI does (or at least, an event is fired, and then you can drive a React render, for example, from that). In contrast, you expect to have to poll an RDBMS for updates. An MIT team recently wrote an awesome essay on the same concept (https://riffle.systems/essays/prelude/), wrapping SQLite for the purpose.

With "data store", rather than "database", I'll admit I am hedging my bets. Through one lens, this library can look more like an app-level store in a classic React sort of way. Through another (most notably the table/row/cell structure), it looks like an RDBMS. I'm not ready to go all-in and declare it's a database yet. Such nomenclature comes with Assumptions™.

A store where you do a query, get a result set, but also a callback (reactivity) in the future if that query would return a different result set if you were to run it again.

Imagine a "row count" HTML element which is automatically updated (reactive) when a different part of the web app inserts a row in the data store.