Skip to content
XTDB

Mission

XTDB is an immutable, time-travel database designed for building complex applications, and to support developers with features that are essential for meeting common regulatory compliance requirements.

Temporal querying has been identified as a hard problem in SQL database for decades, and XTDB is the first ground-up realization of the 'bitemporal model', but XTDB’s temporal powers have benefits for all kinds of applications - not just advanced scenarios in specific domains.

Time Matters

At JUXT, the company behind XTDB, our mission is to simplify how the world makes software.

Experience has made clear to us that no single piece of software infrastructure is more central to the success of an IT system than a well-designed database. However, we believe existing database technologies (Postgres, SQL Server, MongoDB etc.) are far from "finished" and that many important problems still remain unsolved across the database industry. Instead, these problems are left for users of such databases to work around and solve ad-hoc in their application code.

One of the biggest sources of complexity in application code we hope to address is time, and therefore XTDB is a database built for the hard problems of: accurate record keeping (with full ACID transaction support), time-travel queries (XT stands for "across time"), and data evolution. These problems are most acute wherever an organization is handling regulated data.

The Problems

In this era of rapidly evolving regulatory requirements, we see an increasing number of organizations across all industries feeling frustrated by the friction with update-in-place databases that don’t support basic auditing requirements, let alone the accurate time-based versioning that many applications working with regulated data demand.

From GDPR to HIPAA to MiFID II, all kinds of regulatory requirements justify a fundamental level of accuracy and accountability in how your software stack stores and represents key information. The implications extend across the entire transactional to analytical data lifecycle. XTDB is our answer for how a database can better support developers with satisfying basic regulatory requirements, thanks to its ubiquitous 'bitemporal' time-based versioning of records.

We believe that DIY versioning within database schemas should be a thing of the past, and that all database technologies should offer reliable & well-understood methods for versioning. Preserving historical data should not have to be an explicit process which requires conscious design effort and careful development work.

In support of this mission, XTDB solves 4 distinct problems we see with existing databases:

  1. Inconsistent reporting over historical data - accurate reporting requires some notion of "time travel" queries, but without a stable bitemporal basis enforced by the database ad hoc solutions will inevitably resort to copying snapshots of entire data sets in a search for consistency.

  2. Inadequate auditing & compliance - audit tables and triggers and change data capture are all workarounds for the absence of basic audit facilities within a database.

  3. Challenging data integration & evolution - strict schema definitions, update-in-place mutations, and poor support for semi-structured data are all impediments to using relational databases as integration points.

  4. Difficulty of managing SQL with an ad hoc bitemporal schema - composing SQL is unnecessarily hard and is a common source of developer friction. Bitemporal versioning makes it harder still.

The Solution

We have designed XTDB to solve each of these problems in a cohesive way that we believe can reduce the time & costs required for organizations to build and maintain safe systems of record and their associated APIs.

For the everyday application developer who is not working on regulated systems and is less concerned about the nuanced understanding and implications of bitemporal modelling, it is sufficient to simply be aware that the model underpins three distinct layers of capabilities, which the documentation explains in depth. In order of significance:

  1. Basis - using a timestamp as a stable basis for querying prior database states - an essential safety net for developers and organizations alike - and the key to consistent downstreaming processing (e.g. creating a businss KPI report without ETL)

  2. System-Time - a pair of hidden timestamp columns built-in to every table, maintained automatically, that can be used to retrieve old versions of data

  3. Valid-Time - an advanced versioning mechanism that is helpful for scheduling changes across data, and critical for time-aware applications where system-time alone is not enough

First and foremost, XTDB is built to reduce the risks and impact of data loss, update anomalies and brittle database designs. It achieves this goal primarily by always recording the history of all changes (particularly UPDATEs and DELETEs which are normally destructive operations), and by restricting the scope of concurrent database usage, such that an auditable, linear sequence of all changes is retained.

Beyond the obvious auditing and debugging benefits of retaining change data and prior database states, XTDB’s history-preserving capability presents a robust & stable source of truth - a basis - within a wider IT architecture that is unlike anything that most databases can offer.