ArchitectureA supervised JVM-class runtime — OLTP on seven engines, OLAP on three. AI-native, MCP-native, observable as plain SQL.Read the architecture
Está viendo la edición Perú. Está viendo la edición Colombia. You're viewing the Pakistan edition. Cambiar a la edición global →Cambiar a la edición global →Switch to the global edition →

Revision history captured by the database itself, on Informix and PostgreSQL

A diff function runs inside the engine, as a C routine on Informix and PL/pgSQL on PostgreSQL, emitting the RCS script the platform already replays. A trigger can call it, so no write escapes versioning.

The platform versions dictionary code by storing deltas, and the delta was computed by the application. A migration tool or a direct SQL statement bypassed it, and that version was lost. A trigger cannot be bypassed, so the diff had to run where the trigger runs.

Two implementations, one output

  • Informix A C routine compiled server-side, implementing the Myers algorithm, returns the standard RCS edit script that GNU diff emits. The existing Java and JavaScript readers replay it unchanged.
  • PostgreSQL The same function in PL/pgSQL, deliberately not C, so it deploys as ordinary SQL on RDS, Aurora and Cloud SQL where extensions are not permitted. A 5,000-line document with fifty edits diffs in about 17 milliseconds.

Proven

  • Replayable and minimal Tests assert that every script replays to the target and is minimal against a brute-force longest-common-subsequence reference, not that it is byte-identical to the Java engine.
  • Identical across engines Byte-identical scripts over a randomised corpus of 3,000 cases.
  • Acceptance One hundred generated pages, five edits each, and all six hundred versions reconstructed from the delta table alone, on both engines.

Versioning that depends on every writer being well-behaved is not versioning. Now the table versions itself.