sirixdb/sirix
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. observed · 2026-08-28
Health v2 · maintenance only
97/100
- Activity 99
- Release rhythm 93
- Longevity 100
How is this computed?
round(0.45*activity + 0.35*rhythm + 0.20*longevity); archived -> min(score, 10) — computed 2026-09-03. Adoption (stars, forks) is never an input.
- gap_med: 0
- age_days: 5199
- days_rel: 49
- days_push: 7
- n_releases_24m: 28
Adoption not part of the score
1216 stars · 249 forks observed · 2026-08-28
What it is AI-extracted, prompt v1, taxonomy v1, 2026-08-30, confidence not recorded
SirixDB is an embeddable, bitemporal, append-only database system for JSON and XML that stores immutable, space-efficient snapshots of every revision via structural sharing and a sliding-snapshot versioning algorithm. It ships as a JVM library, a Vert.x-based REST server with Keycloak auth, CLI tools, and a web GUI for time-travel queries and revision diffing.
Use cases
- query any past revision of a JSON or XML document as fast as the current one
- build audit trails without bolt-on audit tables or change-data-capture
- track bitemporal data with both transaction time and valid time
- diff two arbitrary revisions of a document
- store evolving documents with full history and minimal storage overhead
- roll back a resource to a previous revision after an error
- replace event sourcing when replaying logs is too costly
When to choose
- you work with document (JSON/XML) data and need deep tree-level versioning
- storage efficiency matters and you want no background compaction or WAL
- you need built-in diffing between arbitrary revisions
- regulatory or audit requirements demand full bitemporal history
- you want an embeddable JVM storage engine with MVCC
When to avoid
- you need SQL compatibility or a managed cloud service today
- you need clustering, replication, or multi-node consensus (single-node only)
- your data model is entity/tuple-oriented rather than document trees
- you need a fully stable 1.0 release (currently 1.0.0-beta with stabilizing on-disk format)
- you need high write throughput on random in-place updates rather than append-only versioning
Facets
library · maturity active
database search-engine serialization databases developer-tools jvm self-hosted bitemporal append-only time-travel versioning json-store xml-store event-store structural-sharing rest-api jsoniq xquery data-engineering linux docker
10 sources
- readme: https://github.com/sirixdb/sirix · fetched 2026-08-28 · 1494ec939e0b
- homepage: https://sirix.io · fetched 2026-08-29 · 060316d7e64f
- site_page: https://sirix.io/docs/index.html · fetched 2026-08-29 · 2a97966c15a4
- site_page: https://sirix.io/docs/getting-started.html · fetched 2026-08-29 · 3b56203ab572
- site_page: https://sirix.io/docs/features.html · fetched 2026-08-29 · 94b38f30436a
- site_page: https://sirix.io/docs/architecture.html · fetched 2026-08-29 · 97a6d8212aca
- site_page: https://sirix.io/docs/comparison.html · fetched 2026-08-29 · 5a359f1ccc63
- site_page: https://sirix.io/docs/use-cases.html · fetched 2026-08-29 · 1585889f2e72
- site_page: https://sirix.io/docs/operations.html · fetched 2026-08-29 · 0133f4fe0fbe
- site_page: https://sirix.io/docs/rest-api.html · fetched 2026-08-29 · 01e9262f26b3
Member repositories
| Repository | Role | Health v2 |
|---|---|---|
| sirixdb/sirix | main | 97 |
For agents
Data as of 2026-08-30T08:39:29.467469+00:00 · Report a problem