SirixDB is an an embeddable, bitemporal, append-only database system and event store, storing immutable lightweight snapshots. It keeps the full history of each resource. Every commit stores a space-efficient snapshot through structural sharing. It is log-structured and never overwrites data. SirixDB uses a novel page-level versioning approach. (by sirixdb)

Sirix Alternatives

Similar projects and alternatives to sirix

  • Appwrite

    582 sirix VS Appwrite

    Your backend, minus the hassle.

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
  • Pandas

    400 sirix VS Pandas

    Flexible and powerful data analysis / manipulation library for Python, providing labeled data structures similar to R data.frame objects, statistical functions, and much more

  • Ansible

    392 sirix VS Ansible

    Ansible is a radically simple IT automation platform that makes your applications and systems easier to deploy and maintain. Automate everything from code deployment to network configuration to cloud management, in a language that approaches plain English, using SSH, with no agents to install on remote systems.

  • jq

    306 sirix VS jq

    Discontinued Command-line JSON processor [Moved to:] (by stedolan)

  • nushell

    A new type of shell

  • gron

    64 sirix VS gron

    Make JSON greppable!

  • miller

    Miller is like awk, sed, cut, join, and sort for name-indexed data such as CSV, TSV, and tabular JSON

  • SaaSHub

    SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

    SaaSHub logo
  • sqlglot

    56 sirix VS sqlglot

    Python SQL Parser and Transpiler

  • fx

    50 sirix VS fx

    Terminal JSON viewer & processor

  • dasel

    Select, put and delete data from JSON, TOML, YAML, XML and CSV files with a single tool. Supports conversion between formats and can be used as a Go package.

  • matplotlib

    36 sirix VS matplotlib

    matplotlib: plotting with Python

  • JRuby

    24 sirix VS JRuby

    JRuby, an implementation of Ruby on the JVM

  • go-mysql-server

    A MySQL-compatible relational database with a storage agnostic query engine. Implemented in pure Go.

  • brackit

    Query processor with proven optimizations, ready to use for your JSON store to query semi-structured data with JSONiq. Can also be used as an ad-hoc in-memory query processor.

  • zed

    13 sirix VS zed

    A novel data lake based on super-structured data (by brimdata)

  • jfq

    13 sirix VS jfq

    JSONata on the command line

  • keycloak-kafka

    Keycloak module to produce events to kafka

  • CXXGraph

    Header-Only C++ Library for Graph Representation and Algorithms

  • hash4j

    Dynatrace hash library for Java

  • Sinatra

    10 sirix VS Sinatra

    Classy web-development dressed in a DSL (official / canonical repo)

  • SaaSHub

    SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

    SaaSHub logo
NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better sirix alternative or higher similarity.

sirix discussion

Log in or Post with

sirix reviews and mentions

Posts with mentions or reviews of sirix. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-01-24.
  • Show HN: Integer Map Data Structure
    3 projects | | 24 Jan 2024
    We're using a similar trie structure as the main document (node) index in SirixDB[1]. Lately, I got some inspiration for different page-sizes based on the ART and HAMT basically for the rightmost inner pages (as the node-IDs are generated by a simple sequence generator and thus also all inner pages (we call them IndirectPage) except for the rightmost are fully occupied (the tree height is adapted dynamically depending on the size of the stored data. Currently, always 1024 references are stored to indirect child pages, but I'll experiment with smaller sized, as the inner nodes are simply copied for each new revision, whereas the leaf pages storing the actual data are versioned themselfes with a novel sliding snapshot algorithm.

    You can simply compute from a unique nodeId each data is assigned (64bit) the page and reference to traverse on each level in the trie through some bit shifting.


  • Endatabas: A SQLite-inspired, SQL document database with full history
    3 projects | | 1 Dec 2023
    I'm working on something similar for the JVM, however with no document semantics, but on a much more fine granular level.

    JSON is shredded during an initial import into a tree structure with fine granular nodes. Thus, an import can be done with very low memory consumption (permitted that auto-commit issues a sync to disk before RAM space is exceeded). Furthermore, it doesn't require a WAL for consistency. Instead the indexes are stored in a log-structure using a persistent tree (as in every commit creates a new tree root). A sliding snapshot algorithm makes sure, that only a fragment of a page has to be copied on a write.

    As thus, it's also a perfect candidate for an event store, storing both the (lightweight) snapshots and tracking the changes optionally.

    The architecture is described over here:

    Furthermore I'm working on a tutorial for a local client usage (work in progress):

    Kind regards

  • Show HN: Bitemporal, Binary JSON Based DBS and Event Store
    6 projects | | 13 Nov 2023
    If anyone is up to building a new frontend, that would be awesome (of course, work could also be split between interested people) :-)

  • Show HN: Light implementation of Event Sourcing using PostgreSQL as event store
    9 projects | | 31 Oct 2023
    I'm working on an append-only (immutable) (bi)temporal DBS[1] in my spare time, which transforms CRUD operations into an event store, automatically providing an audit log for each stored node, while the nodes are stored with immutable node-IDs, which never change. As the contents stored are based on a custom binary JSON format also a rolling hash can optionally be built, to check if a whole subtree has changed or not.

    The system uses persistent index data structures to share unchanged pages between revisions.

    The intermittant snapshots are omitted. Rather the snapshot is spread over several revisions, applying a sliding snapshot algorithm on the data pages (thus, avoiding write peaks, while at max a predefined number of page fragments has to be read in parallel to reconstruct a page in-memory).

    [1] |

  • Show HN: Evolutionary (binary) JSON data store (full immutable revision history)
    3 projects | | 21 Oct 2023
    I've already posted the project a couple of years ago and it gained some interest, but a lot of stuff has been done since then, especially regarding performance, a complete new JSON store, a REST API, various internals refactored, an improved JSONiq based query engine allowing updates, a now already dated web UI, a new Kotlin based CLI, a Python and TypeScript client to ease the use of Sirix...

    First prototypes from a precursor stem already from 2005.

    So, what is it all about?

    I'm working on an evolutionary data store in my spare time[1]. It is based on the idea to get rid of the need for a second trx log (the WAL) by using a persistent tree of tries (preserving the previous revision through copy on write and path copying to the root) index as the log itself with only a single permitted read/write txn concurrently and in parallel to N read-only txns, which are bound to specific revisions during the start. The single writer is permitted on a resource (comparable to a table/relation in a relational DB) basis within a database, reads do not involve any locks at all.

    The idea is, that the system atomically swaps the tree root to the new version (replicated). If something fails the log can simply be truncated to the former tree root.

    Thus, the system has many similarities with Git (structural sharing of unchanged nodes/pages) and ZFS snapshots (regarding the latter the keyed trie has been inspired by ZFS, as well as that checksums for child pages are stored in parent pages in the references to the child pages)[2].

    You can of course simply execute time travel queries on the whole revision history, add commit comments and the author to answer questions such as who committed what at which point in time and why...

    The system not only copies full data pages, but it applies a sliding snapshot versioning algorithm to keep storage space to a minimum.

    Thus, it's best suited for fast flash drives with fast random reads and sequential writes. Data is never overwritten, thus audit trails are given for free.

    The system stores find granular JSON nodes, thus the structure and size of an object has almost no limits. A path summary is built, which is an unordered set of all paths to leaf nodes in the tree and enables various optimizations. Furthermore a rolling hash is optionally built, whereas during inserts all ancestor node hashes are adapted.

    Furthermore it optionally keeps track of update operations and the ctx nodes involved during txn commits. Thus, you can easily get the changes between revisions, you can check the full history of nodes, as well as navigate in time to the first revision, the last revision, the next and previous revision of a node...

    You can also open a revision at a specific system time revert to a revision and commit a new version while preserving all revisions in-between.

    As said one feature is, that the objects can be arbitrarily nested, thus almost no limits in the number and updates are cheap.

    A dated Jupyter notebook with some examples can be found in [3] and overall documentation in [4].

    The query engine[5] Brackit is retargetable (a couple of interfaces and rewrite rules have to be implemented for DB systems) and especially finds implicit joins and applies known algorithms from the relational DB systems world to optimize joins and aggregate functions due to set-oriented processing of the operators.[6]

    I've given an interview in [7], but I'm usually very nervous, so don't judge too harshly.

    Give it a try and happy coding!

    Kind regards


    [1] |







  • Evolutionary, JSON data store (keeping the full revision history)
    3 projects | | 20 Oct 2023
  • Immutable Data
    2 projects | | 26 Jun 2023
    You can use Datomic for instance (mentioned already in your article IIRC!?) or SirixDB[1] on sich I'm working in my spare time.

    The idea is an indexed append-only log-structure and to use a functional tree structure (sharing unchanged nodes between revisions) plus a novel algorithm to balance incremental and full dumps of database pages using a sliding window instead.

    [1] |

  • Java opensource projects that need help from community.
    13 projects | /r/java | 20 May 2023
    Append-only database system (based on a persistent inddx structure): or a retargetable query compiler
  • Looking to help out on some open source projects
    4 projects | /r/opensource | 17 Apr 2023
    You can work on a temporal data store called SirixDB:
  • SirixDB - an embeddable, evolutionary database system
    2 projects | /r/java | 3 Apr 2023
  • A note from our sponsor - InfluxDB | 14 Jun 2024
    Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality. Learn more →


Basic sirix repo stats
8 days ago

Power Real-Time Data Analytics at Scale
Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.