Capture. Transform. Serve.One deployable.
Tapstate taps your production databases with log-based CDC and turns change streams into continuously fresh, queryable views. Applications, APIs, and Agentic AI systems can act on current business state — without a separate Debezium + Kafka + Flink + cache stack.
curl -sSL install.tapstate.dev | sh
Built for platform and data teams keeping operational data current without operating a multi-tool real-time stack.
- Sands
- MGM
- SJM Resorts
- PayU
- Fubon Bank
- Hutchison Telecom
- TCL
- Xiaomi
- Hospital Authority
- FAW
- CSSC / SWS
- Nanjing Steel
THE PROBLEM
You don't need four vendors
to keep data fresh.
CDC tool, Kafka, Flink, and a cache — plus the YAML, headcount, and on-call burden that stitches them together. That's not architecture. It's an assembly project.
Kafka moves events.
Warehouses analyze history.
Tapstate turns database truth into live operational state.
One data path, not three features
One engine, from change capture to live state.
Everyone enters at Capture. From there, teams can expand into in-flight transformation and fresh, queryable state without switching products.
Capture
CDC you can bet the database on
- Log-based CDC
- Initial load + continuous sync
- Ordering and exactly-once consistency semantics
- Checkpointed recovery
- Schema evolution handling across many engines
- Measured, minimal source impact
The trust anchor and front door.
Battle scars, not vision.
Transform
Reshape data in flight, not in batch
- Filter and route change streams
- Enrich and denormalize in flight
- Stateful joins
- Process changes before they land
- No separate stream-processing cluster to manage
The bridge.
CDC users end up writing this glue by hand.
Serve
Fresh state, queryable now
- Integrated, MongoDB-compatible materialized store
- Latest state of accounts, orders, inventory, and entitlements
- Fresh, queryable state for applications, APIs, and AI agents
- Standard drivers — no custom SDK required
The destination.
Where the pipeline was always going.
Start with Capture. Expand into Transform and Serve without changing products.
See it work
Update a record. Query the new state.
Watch one source change move through Tapstate — from capture and in-flight transformation to a fresh, queryable live view.
No separate broker, stream processor, or serving cache in between.
An order is marked as paid.
UPDATE ordersSET status = 'paid'WHERE order_id = 'ORD-1042';Changed
status: pending paid
Tapstate captures and reshapes the change.
- Capture
Change captured from orders
- Transform
Join customer context and enrich fields
- Serve
Materialize into live_order_state
The updated state is ready to query.
db.live_order_state.findOne({order_id: "ORD-1042"})- Captured from source
- Transformed in flight
- Materialized as live state
- Queryable by apps, APIs, and AI agents
Not a demo for the AI era. Infrastructure already carrying production load.
Tapstate is built on the production engine behind TapData, hardened across enterprise CDC and live operational data workloads.
Operate one system
Operate the full data path as one system.
A four-vendor stack may work for nightly reporting. It becomes harder to operate when real-time applications, fraud systems, and AI agents depend on fresh operational state.
One product, one operational surface
Operate capture, transformation, and serving as one system instead of four separately managed layers.
Reliability across the data path
End-to-end ordering, checkpointing, recovery, and consistency semantics from source to served state.
Deploy where your data already lives
Run alongside your production databases — in your VPC, your region, and your compliance boundary.
Lower operational overhead
Reduce the infrastructure and staffing required to run separate Kafka, Flink, and cache layers.
Why freshness matters
AI agents need current business state.
For AI agents and real-time applications, data freshness is a correctness requirement.
- Warehouses are optimized for historical analysis.
- Real-time applications and AI agents depend on current operational state.
- Embeddings add context, but they do not replace current system-of-record state.
- Tapstate combines log-based CDC, in-flight transformation, and queryable serving in one engine.
FAQ
Practitioner objections, answered straight.
Tapstate ships as a single deployable with a bounded, configurable heap. Capture and serving state are checkpointed to disk rather than held entirely in memory, so footprint scales with your working set and parallelism — not with total history.
That is three products with three failure surfaces, three upgrade cycles, and glue between each hop. Tapstate expresses capture, transformation, and serving as one data path in one deployable — you configure a pipeline, not an integration project.
Yes. Initial load and continuous stream share a single checkpointing model, so the cutover from snapshot to log is consistent and idempotent. On recovery, Tapstate resumes from the last committed checkpoint without duplicating or dropping changes.
The integrated serving store speaks the MongoDB wire protocol, so standard drivers, queries, and indexes work against the latest materialized state. It is a serving layer for current operational truth, not a drop-in replacement for every MongoDB feature.
Position in the source log and transformation state are checkpointed. On restart, Tapstate replays from the last checkpoint and reconciles serving state, so a crash costs you recovery time — not correctness.
Build your first Tapstate data path.
curl -sSL install.tapstate.dev | sh