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 →

A change-data-capture server that keeps cluster caches consistent

A standalone capture server reads Informix CDC and PostgreSQL logical replication and publishes cache-invalidation events over Redis. Nodes subscribe with backoff and choose a cache-sync strategy each.

A cluster caches dictionary and configuration data on every node. When a row changes, every node must know. Polling is late and expensive; this release replaces it with capture at the database.

The server

  • Two sources The Informix change-data-capture API and PostgreSQL logical replication, with replica identity handled so deletes carry their key.
  • Filtered Columns can be excluded and tables matched by pattern.
  • Published over Redis Invalidation events go to a channel the nodes subscribe to.
  • Operable An HTTP status API, statistics kept in SQLite with a dashboard, a command-line interface, virtual threads, a native-image build, and a distribution with a daemon script and a systemd example.

The nodes

  • Subscribed with care Separate channels for sessions and cache, reconnection with exponential backoff and jitter, and the cluster cache gated by a property.
  • A strategy per node Each node declares how its caches stay in sync: direct from the database, through Redis, or through capture.

A year later the node learned to watch its own tables in process, without the external server. This release is where capture-driven invalidation began.