Delta-state algebra vs the tools you already know.
Honest trade-offs so you can pick the right tool for the job.
Answer one question and we will point you to the right comparison — and be honest about when ATOMiK is not the best fit.
What is your primary challenge?
Redis, etcd, and ZooKeeper are production-grade data stores with rich ecosystems. ATOMiK is not a replacement for any of them. It solves a narrower problem: evaluating whether state changes can be represented as compact deltas. Where these tools store and serve full key-value pairs, ATOMiK evaluates paths that move deltas and reconstruct current state from an accumulator.
| Feature | ATOMiK | Redis | etcd | ZooKeeper |
|---|---|---|---|---|
| Consistency model | Modeled Abelian-group path | Eventual / strong (configurable) | Linearizable (Raft) | Linearizable (ZAB) |
| Sync bandwidth | Delta-sized in mapped paths | Full key-value per write | Full key-value per write | Full znode per write |
| Coordination needed | Workload-dependent | Leader for writes (Cluster) | Leader election required | Leader election required |
| Write latency | Evaluation-dependent | Sub-ms (single node), variable (cluster) | ~10ms (Raft consensus round) | ~10ms (ZAB proposal round) |
| State reconstruction | O(1) — initial ⊕ accumulator | O(1) key lookup (stored in memory) | O(1) key lookup (stored in memory) | O(1) znode read (stored in memory) |
| Formal proofs | Formal proof work | No formal verification | TLA+ spec (partial) | No formal verification |
Ready to switch?
Migration Guide: From CRDTs to ATOMiKKafka and event sourcing give you ordered, replayable event logs with rich consumer ecosystems. CRDTs give you conflict-free convergence. ATOMiK overlaps with CRDTs conceptually (both converge without coordination), but uses a stricter algebraic structure (Abelian group vs. join-semilattice) that also provides free undo via self-inverse deltas. The trade-off: ATOMiK does not store individual events and has no concept of consumer groups or partitions.
| Feature | ATOMiK | Kafka | Event Sourcing | CRDTs |
|---|---|---|---|---|
| Storage growth | Constant (single accumulator) | Linear (log retention) | Linear (event log) | Proportional to state size |
| Replay cost | No event replay in modeled path | O(n) — scan from offset | O(n) — replay all events | O(1) — merge states directly |
| Undo / rollback | Re-apply same delta (self-inverse) | Produce compensating event | Produce compensating event | Not generally supported |
| Conflict resolution | Algebraic in scoped model | Partition-based ordering | Application-level logic | Automatic (join-semilattice) |
| Bandwidth per update | Size of changed fields only | Full message payload | Full event payload | State or op payload (varies) |
| Ordering requirement | None — commutative + associative | Total order per partition | Total order per aggregate | None (op-based) / causal (state-based) |
Ready to switch?
Migration Guide: From Event Sourcing to ATOMiKTraditional change detection often scans full content or walks a tree. ATOMiK evaluates whether an accumulator comparison can replace that repeated work in a scoped path. Timing-side-channel claims still require a measured workload, threat model, and deployment boundary.
| Feature | ATOMiK | Checksums (SHA/MD5) | Diff / Patch | Merkle Trees |
|---|---|---|---|---|
| Detection complexity | Accumulator comparison in scoped path | O(n) — hash full content | O(n) — byte-by-byte comparison | O(log n) — walk tree path |
| Per-page cost | Compact XOR path when hardware-backed | Full hash computation | Full content scan | Hash per node on path |
| False negative rate | Depends on representation and threat model | Negligible (collision probability) | Zero | Negligible (collision probability) |
| Deterministic timing | Requires measured workload boundary | No — data-dependent | No — data-dependent | Partially — fixed-depth trees only |
| Side channels | Requires threat-model review | Timing varies with input | Timing varies with differences | Path-dependent timing |
Ready to get started?
Getting Started with ATOMiK Change DetectionGPUs excel at massively parallel floating-point work (ML, graphics). ASICs deliver the highest performance per watt for a fixed function. ATOMiK targets FPGA because delta-state operations are simple, wide, and embarrassingly parallel—a natural fit for configurable fabric. Development-board and Zynq work should be quoted only through the hardware validation map, with synthesis output kept separate from live-board benchmark claims.
| Feature | ATOMiK FPGA | GPU Computing | ASIC (custom) |
|---|---|---|---|
| Operations/sec | Synthesis-characterized Zynq scaling | Tera-scale (matrix ops) | Application-specific, highest |
| Dev board cost | Low-cost dev boards available | $200+ (entry-level) | $100K+ (tape-out) |
| Power consumption | Artifact-required | 75–350W (typical GPU) | Lowest for given task |
| Formal verification | Formal proof work + RTL/synthesis artifacts | Numerical verification only | Full verification possible |
| Time to prototype | Workload-dependent | Days (CUDA/OpenCL) | 12–18 months (fab cycle) |
Not a database
ATOMiK has no query language, no indexes, no transactions. If you need to store and query structured data, use PostgreSQL, Redis, or DynamoDB.
Not a message queue
ATOMiK does not provide ordered delivery, consumer groups, or dead-letter queues. If you need reliable message routing, use Kafka, RabbitMQ, or SQS.
Not cryptographic hashing
XOR-based accumulation is not collision-resistant in a cryptographic sense. Do not use ATOMiK as a substitute for SHA-256 in security contexts.
No built-in audit trail
Delta-state algebra accumulates changes into a single value. Individual deltas are not stored. If you need a full event history, use event sourcing or an append-only log.
Not for rich data transformations
ATOMiK tracks whether state changed and what the current state is. It does not map, filter, aggregate, or join data. Use Flink, Spark, or Kafka Streams for stream processing pipelines.
Start with the evidence framework, then bring a concrete workload if the algebra looks relevant.