Hi all,<p>Sebastian and his students did a tremendous job creating Brackit[1] in the first place as a retargetable query engine for different data stores. They worked hard to optimize aggregations and joins. Despite its clear database query engine routes, it's furthermore useable as a standalone ad-hoc in-memory query engine.<p>Sebastian did his research for his Ph.D. at the TU-Kaiserslautern at the database systems group of Theo Härder. Theo Härder coined the well-known acronym ACID with Andreas Reuter, the desired properties of transactions.<p>As he's currently not maintaining the project anymore, I stepped up and forked the project a couple of years ago. I'm using it for my evolutionary, immutable data store SirixDB[2], which stores the entire history of your JSON data in small-sized snapshots in an append-only file (tailored binary format similar to BSON). It's exceptionally well suited for audits, undo operations, and sophisticated analytical time travel queries.<p>I've changed a lot of stuff, such that Brackit is getting more and more compatible with the JSONiq query language standard, added JSONiq update primitives, and fixed several bugs. Furthermore, I've added temporal extension functions and temporal XPath axis in SirixDB, index rewrite rules, etc. pp.<p>As Brackit can query XML, we're also able to transform XML data to JSON and vice versa.<p>Moshe and I are working on a Jupyter Notebook / Tutorial[3] for interactive queries.<p>We're looking forward to your bug reports, issues, and questions. Contributions are, of course, highly welcome. Maybe even implementations for other data stores or common query optimizations.<p>Furthermore, we'd gladly see further (university-based?) research.<p>It should, for instance, be possible to add vector instructions in the future, as the query engine is already set-oriented and processes sets of tuples for the so-called FLWOR expressions (see JSONiq). Brackit rewrites FLWOR expression trees in the AST to a pipeline of operations to port optimizations from relational query engines for efficient join processing and aggregate expressions. Furthermore, certain parts of the queries are parallelizable, as detailed in Sebastian's thesis. We also envision a stage for the compiler to use distributed processing (first research used MapReduce, but we can now use better-suited approaches, of course).<p>Kind regards
Johannes<p>[1] https://github.com/sirixdb/brackit<p>[2] https://sirix.io | https://github.com/sirixdb/sirix<p>[3] https://colab.research.google.com/drive/19eC-UfJVm_gCjY--koOWN50sgiFa5hSC