# Drasi: change data capture with continuous Cypher queries > Drasi is a CNCF sandbox project that watches data sources for changes, evaluates those changes with continuous queries written in Cypher, and fires reactions when the query result sets change. It is built to avoid copying data into a central lake and to avoid polling sources repeatedly, and the project describes itself as an early release meant for proofs of concept. **drasi-project/drasi-platform** — The Data Change Processing platform - Repository: https://github.com/drasi-project/drasi-platform - Website: https://drasi.io/ - Stars: 1,256 · Forks: 89 - Language: C# - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/drasi-project-drasi-platform ## Sources, continuous queries, reactions Drasi is described as a data processing platform that simplifies detecting changes in data and taking immediate action, and it is built from three components. Sources connect to data repositories within software systems to monitor logs and feeds and track changing data. Continuous Queries interpret those monitored changes by applying criteria and conditions to identify significant changes, and they are written in the Cypher Query Language. Reactions trigger meaningful responses when the result sets of the Continuous Queries are updated. The order matters. A Source does not decide what is interesting, it only reports what changed. A Continuous Query does not act, it decides what is interesting and holds the current result set. A Reaction is the only part that has side effects, and it fires when the result set changes rather than on every event. That separation is the design that makes the platform more than a pipeline with a filter step, and it is also what lets the same query feed several different reactions. The stated benefit is real-time actionable insight without the overhead of traditional data processing methods. Drasi tracks system changes and events without needing to copy data to a central data lake or repeatedly query the data sources, which is the cost the project is positioned against. ## Cypher is the query language, and the result set is the trigger Using Cypher is the single most consequential choice in the design. A continuous query is not a one-shot statement, it is a standing query whose result set is maintained as the underlying data changes, and the platform reacts to changes in that result set. That model has a clear consequence for how you write them. A query that matches nothing, or matches the same set as before, produces no reaction, so the interesting behaviour is a query whose result set gains or loses rows. A rule that fires on every event is expressed as a query whose result changes on every event, which is a different thing to write and to reason about. The Cypher choice also means the query language is one people already have a grammar for, whether from graph databases or from analytics work, and it means the queries are not locked to a bespoke DSL that has to be learned before anything can be built. The price is that the semantics of a continuous query are not exactly the semantics of Cypher as used elsewhere, since the result set is a maintained thing rather than the output of a single evaluation. The documentation site is where that distinction is spelled out, and the tutorial pages for Kubernetes are the entry point. Drasi also carries an OpenSSF Best Practices badge, which is a signal about how the project expects to be run, and the repository is a CNCF Sandbox project, so governance and maturity sit at the earlier end of the foundation's ladder. ## The curbside pickup example, which is not a toy The README illustrates the three-component model with a delivery system for an online ordering service, and it is worth reading closely because the example is about a real operational problem rather than about monitoring. Orders are processed through an order management system, and delivery drivers need real-time notifications when orders are ready for pickup. The setup has three parts. A Source is configured to monitor the order management system for changes in order statuses, and a second Source detects when a driver becomes available for a delivery run. A Continuous Query then combines data from both Sources to match orders ready for pickup with available drivers. A Reaction is defined to send alerts to drivers, notifying them to proceed to the pickup area. What the example demonstrates is the join across two Sources in a single query, and the fact that the reaction is about a state, not an event. The driver is notified when an order becomes ready and a driver becomes available at the same time, which is a condition over two streams. Polling either system for that condition is expensive and slow, and a central copy of both would be more infrastructure than the problem deserves. The claimed outcome is that drivers are informed promptly, with real-time data integration and automated responses doing the work. Whether the reaction reaches a phone, a dispatch screen or a queue is a property of the Reaction you configure, and the README does not narrow that down. ## Building the platform is four sub-projects and one Makefile The repository is a monorepo with one Makefile delegating to four component trees. The top-level entries are control-planes/, query-container/, sources/ and reactions/, plus cli/, typespec/, e2e-tests/, infrastructure/, dev-tools/ and docs/. The build target recurses into each of the four: ```make default: docker-build docker-build: $(MAKE) -C control-planes $(MAKECMDGOALS) $(MAKE) -C query-container $(MAKECMDGOALS) $(MAKE) -C sources $(MAKECMDGOALS) $(MAKE) -C reactions $(MAKECMDGOALS) ``` The same four-way recursion repeats for kind-load and k3d-load, which load the built images into a local Kubernetes cluster with either kind or k3d, and for test and lint-check. That two-target-per-cluster pattern is a small sign of care about the developer loop, since both common local cluster tools are supported. The presence of rust-toolchain.toml next to a C# primary language is worth a moment's attention. The primary language of the repository is recorded as C#, and a Rust toolchain file at the root means at least part of the platform is written in Rust, most plausibly the query container that evaluates the continuous queries. The typespec/ directory points to a formal API description, which is what a Source or a Reaction would implement against. So the platform is not one binary. It is a control plane, a query container, a set of source plugins and a set of reaction plugins, and a deployment has to place all four. ## Getting started is three steps, all on Kubernetes The Getting Started section sends you to a Kubernetes tutorial, and the three steps map one to one onto the three components. You apply a Source representing the data source whose changes you want to observe. You create Continuous Queries to define the data to observe, the conditions to assess changes and the structure of the output. You then apply a Debug Reaction to view the output generated by one or more Continuous Queries. Starting with a Debug Reaction rather than a real one is the right instinct, and the tutorial evidently takes it, because the failure mode of a continuous query system is a query that fires on everything, and that is much easier to spot in a debug view than in a driver's phone. The rest of the documentation is organised by audience and by task. There are tutorial pages and how-to guides for Drasi for Kubernetes, and the site is the reference for the sources and reactions available. The README notes that this repository contains everything required to build a Drasi-based solution with Sources, Reactions, and tooling for development and testing, which covers both the platform and the bundled Sources and Reactions. The tutorial and how-to guides are the fastest way to see which Sources and Reactions are available. ## Where Drasi is the wrong tool The first wrong-tool case is a production platform with a support commitment. The release status section is unambiguous: this is an early release of Drasi for the community to learn about the platform and experiment with in proofs of concept, and the invitation is to create GitHub issues for bugs and feature requests. That is a project asking for feedback, not a project making a stability promise. The second is a use case that a query engine already covers. If the question is a periodic aggregation over a database, the CDC and query layers in your warehouse or database already do that, and adding a platform with a control plane, a query container and a plugin model is overhead. Drasi earns its place when the reaction has to happen quickly and the data is spread across systems that are not designed to be joined, which is exactly the curbside pickup case, and not otherwise. The third is a team that does not want to run Kubernetes or a set of containers. The getting started path is Kubernetes, the Makefile targets load images into kind or k3d, and the four components are separate deployment units. There is no single-binary or library mode described in the README, so an embedded or single-host deployment means assembling it yourself. ## Apache-2.0, sandbox status and version 0.10.0 The project is licensed under the Apache 2.0 licence, with the LICENSE file in the repository root and the README pointing at the community repository's copy of it. The release list shows 0.10.0 dated 2025-11-21, 0.9.2 from 2025-11-11 and 0.9.1 from 2025-10-24, so the version moved fast through the 0.9 and 0.10 lines in a few weeks, which is normal for a sandbox project iterating with early users. The last push was on 2026-10-10, so the work continues between releases. The Apache-2.0 grant matters for a platform, because a Source or a Reaction you write is a separate work against a permissive licence, and there is no copyleft obligation that reaches into the surrounding system. That is a genuine advantage when a company wants to contribute a connector back without legal review of the whole platform. On maturity, the CNCF Sandbox placement is the honest signal, and the README's release status wording is the second one. The documentation lives on drasi.io, the community and contribution guidance live in the drasi-project/community repository, and the Discord server is where the maintainers say questions should go, with an email address at info@drasi.io as the alternative. There is also a security disclosure guide and a code of conduct, both in the community repository, which is the standard arrangement for a project at this stage. ## Conclusion Adopt Drasi for a proof of concept or an internal platform team that wants event-driven reactions to changes in operational data, and start with the Kubernetes tutorial, a Source, one Continuous Query and a Debug Reaction, because the project explicitly positions itself as an early release for experimentation. Do not adopt it as the backbone of a production data platform, since the release status section says it is an early release for the community to experiment with, and do not adopt it if your team cannot take on a platform with four deployable components. Before you commit, read the release status section again, check the Apache-2.0 licence, and confirm with the maintainers on Discord what the upgrade path looks like once you leave proof of concept stage. ## FAQ ### What are the three components of Drasi? Sources connect to data repositories to monitor logs and feeds for changing data, Continuous Queries interpret those changes using criteria and conditions and are written in Cypher, and Reactions trigger responses when the result sets of those queries are updated. ### Which query language do Drasi continuous queries use? The Cypher Query Language. Drasi queries are standing rather than one-shot, so their result sets are maintained as data changes, and it is those result set updates that trigger reactions. ### How do I start using Drasi? Follow the Getting Started tutorial for Drasi for Kubernetes. You apply a Source for the data source you want to observe, create Continuous Queries that define the data, the conditions and the output structure, and apply a Debug Reaction to view the output. ### Is Drasi ready for production use? The release status section describes it as an early release for the community to learn about the platform and experiment with in proofs of concept, and asks for GitHub issues for bugs and feature requests. It is a CNCF Sandbox project. ### What licence does Drasi use? Apache 2.0, with the LICENSE file in the repository root. The most recent listed release is 0.10.0, dated 2025-11-21, and the last push was on 2026-10-10. ## Sources - [drasi-project/drasi-platform on GitHub](https://github.com/drasi-project/drasi-platform) - [License: Apache-2.0](https://github.com/drasi-project/drasi-platform/blob/main/LICENSE) - [Project website](https://drasi.io/) - [README](https://github.com/drasi-project/drasi-platform/blob/main/README.md) - [Releases](https://github.com/drasi-project/drasi-platform/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/drasi-project-drasi-platform