Capture. Transform. Serve.One binary.
Tapstate taps your production databases with log-based CDC, joins and reshapes change streams in flight, and serves continuously fresh, queryable views — replacing the Debezium + Kafka + Flink + cache stack with a single deployable you can run in minutes.
curl -sSL install.tapstate.dev | sh
- RBC
- Sands
- MGM
- SJM Resorts
- Hotel Lisboa
- PayU
- Fubon Bank
- Bank of China (HK)
- BOC Life
- Hutchison Telecom
- TCL
- Xiaomi
- Hospital Authority
- Orient Securities
- 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
Everyone enters at Capture.
Where they stop depends on how far they want to expand — not on a different product. Capture, Transform, and Serve are three depths of adoption along a single data path.
Capture
CDC you can bet the database on
- Log-based CDC
- Initial load + continuous sync
- Ordering guarantees
- Checkpointed recovery
- Exactly-once / consistency semantics
- Schema evolution handling
- Measured, minimal source impact
- Proven across many engines
The trust anchor and front door.
Transform
Reshape data in flight, not in batch
- Filter
- Route
- Enrich
- Denormalize
- Stateful joins
- Process change streams before they land
- No separate stream-processing cluster to manage
The bridge.
Serve
Fresh state, queryable now
- Integrated, MongoDB-compatible materialized store
- Latest state of accounts, orders, inventory, entitlements
- Queryable directly by apps, APIs, and agents
- Standard drivers — no custom SDK required
The destination.
Not a demo for the AI era. Infrastructure already carrying production load.
Tapstate is built on the engine behind Tapdata — a log-based CDC and live data platform hardened through production workloads across APAC. The category is new; the engine is not.
* Placeholder figures pending verification.
For platform & data leaders
Replace the assembly project. Keep the SLA.
Four vendors were tolerable when the consumer of your data was a nightly dashboard. They are not tolerable when the consumer is a real-time application, a fraud model, or an agent that acts.
One vendor, one support line
Replace four integration points and their four escalation paths with a single product and a single owner.
Reliability you can put in an SLA
End-to-end ordering, checkpointing, and consistency semantics you can actually commit to in a contract.
Deploy where your data already lives
Run it next to your production databases — your VPC, your region, your compliance boundary.
Lower total cost of the pipeline
No Kafka cluster, no Flink cluster, no cache tier to staff, size, and pay for separately.
For investors & strategic readers
The infrastructure AI adoption makes mandatory.
AI adoption converts data freshness from a nice-to-have into a correctness requirement.
- Historical data clouds solved analysis.
- AI shifts demand toward fresh operational state.
- AI agents need committed business truth, not just embeddings.
- Tapstate owns transaction-log-grade CDC + stateful transformation + serving.
The moat
Transaction-log-grade CDC plus stateful transformation and serving — the hardest, least sexy, most defensible layer of the stack.
The expansion proof
Capture is the front door; Transform and Serve are natural, in-product expansion — land narrow, grow inside the same deployable.
Why incumbents can't easily follow
Warehouse-native vendors are architected for batch history, not committed operational truth. Unifying the operational path is a different product.
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.
Delete the assembly project. Keep the data fresh.
curl -sSL install.tapstate.dev | sh