Siddhi Core Libraries for Java and Python Stream Processing

What Siddhi Core Libraries solve

Siddhi addresses applications that must treat a continuous event stream as more than a sequence of independent records. The README describes support for streaming and Complex Event Processing, including capturing events from diverse sources, processing them, detecting complex conditions, and publishing results to endpoints in real time. This is relevant to fraud detection, monitoring, operational alerts, and other systems where the relationship among several events matters.

The repository is not the whole Siddhi product surface. It is the collection of core libraries needed for Siddhi execution. The README identifies `siddhi-core`, `siddhi-query-api`, `siddhi-query-compiler`, and `siddhi-annotations` as the essential modules. That division matters to engineers evaluating dependencies. Someone looking for an application to deploy immediately should inspect the separate runtime and tooling downloads. Someone embedding query execution into an existing Java or Python application is looking at the right repository.

Siddhi can run as an embedded Java and Python library, as a microservice on bare metal, a VM, or Docker, and natively in Kubernetes. These are deployment modes stated by the README, not separate features implemented by this repository alone. The core-library package is therefore the foundation for several operating models rather than a prescribed deployment.

The query-to-event pipeline

The documented processing model begins with Streaming SQL queries. Siddhi uses those queries to define how incoming events are captured, processed, correlated, and emitted. A query is compiled through the dedicated query compiler module, while `siddhi-query-api` provides the query-facing API and `siddhi-core` supplies the execution libraries. The README does not expose the internal classes or a complete data-flow diagram in text, so the exact runtime call sequence should be taken from the API documentation and the relevant module documentation.

The important architectural distinction is between a query language and a stream processor. Streaming SQL gives the application a declarative way to describe event streams and conditions, while the core runtime executes those definitions. The result can be consumed by downstream endpoints, which makes Siddhi useful as a processing layer between event inputs and alerting, storage, or service outputs. The exact source and sink integrations are not listed in this repository README, so a project should verify the required integration modules separately.

Because the repository contains multiple Maven modules, it is a library composition rather than one standalone executable. The module boundaries also provide clues for upgrade planning. Changes to the query API or compiler may affect applications that build queries programmatically, while changes to the core runtime may affect event handling behavior. Engineers should avoid assuming that the API documentation version, latest release, and default branch version are interchangeable until compatibility has been checked.

Getting Siddhi Core Libraries

The README directs users to the Siddhi Quick Start Guide and the Siddhi Documentation, but it does not provide a self-contained install command, Maven dependency snippet, or runnable first query in the repository text. The following is therefore a source-selection tutorial rather than a fabricated installation walkthrough.

First, choose the major version line. The README states that versions 5.x and above use group IDs beginning with `io.siddhi.*`, while versions 4.x and lower use group IDs beginning with `org.wso2.siddhi.*`. For 5.x, obtain the relevant Siddhi Core Libraries artifacts from the `io.siddhi.*` Maven repository entry. The README does not specify which individual artifact coordinates to add to an application, so select modules only after checking the Quick Start Guide and the module documentation.

Second, if the goal is to deploy Siddhi rather than embed it, use the separate Siddhi tooling and runtime distribution download. The README lists bare-metal, VM, Docker, and Kubernetes execution forms, but the repository README does not include container commands, Kubernetes manifests, ports, or environment variables. Those values should not be guessed. A first real use for an embedded integration should begin with the official Quick Start Guide, add the documented dependencies for the chosen 5.x line, create a minimal Streaming SQL definition, and publish a test event through a documented input and output integration.

Where the library boundary creates friction

The clearest limitation is scope. Siddhi Core Libraries are not presented as a complete standalone distribution. The README separates core library downloads from tooling and runtime distributions, which means a developer may need to assemble or download several pieces before a service can run. That is a poor fit for a team that wants one packaged executable from this repository alone.

The README does not identify the supported source and sink integrations, persistence model, deployment configuration, scaling behavior, or transaction semantics. Those omissions do not establish that the features are absent. They establish that an adoption decision cannot be made from the README alone. In particular, a system that depends on durable recovery, exactly-once processing, horizontal partitioning, or a particular message broker needs direct confirmation from the relevant Siddhi documentation and extension documentation.

The API documentation link points to version 5.1.33, while the listed recent release is v5.1.31. That difference is visible in the README and should be treated as a version-checking issue. It may indicate that generated API documentation can be newer than the latest release listed in the repository record, or simply that the README was not synchronized. Engineers should verify the artifact version and API version together before writing integration code.

Siddhi versus a plain application-side stream loop

A realistic alternative is an application-owned stream processor implemented with a message-consumer loop, state stores, timers, and custom correlation rules. That approach can be simpler when the processing logic is small and the application already controls the event schema. It also avoids introducing a query compiler and a separate execution model. The trade-off is that every pattern, such as joining events across time windows or detecting compound conditions, becomes application code and test infrastructure.

Siddhi takes a different approach by expressing those patterns in Streaming SQL and delegating execution to the Siddhi runtime. Its value is clearest when the same logic must be reused across embedded and service deployments, or when operators need a query-oriented interface rather than a collection of custom consumers. The cost is an additional runtime, dependency compatibility work, and a need to understand Siddhi's stream semantics.

The repository README does not provide a benchmark or a comparison with Apache Flink, Kafka Streams, or another CEP product, so a performance or operational superiority claim is not supportable. The decision should compare deployment shape, language integration, query semantics, state handling, and the availability of the required connectors against the existing application architecture.

Licensing, maintenance, and upgrade cost

Siddhi is identified by the repository as Apache-2.0 licensed. That license is relevant when selecting dependencies, distributing modifications, or reviewing notice and attribution obligations, although this article does not provide legal advice. The repository includes a `LICENSE` file and links the Apache 2.0 license in the README.

The repository is not archived, and the last push was on 2026-10-08. The recent release list includes v5.1.31 on 2026-04-08, v5.1.30 on 2024-01-17, and v5.1.27 on 2023-02-01. Those dates describe the release and repository activity available here; they do not establish a support commitment for any particular integration. Upgrade planning should therefore account for testing the compiler, API, runtime, and extension combination rather than changing only one top-level version.

The module structure creates a concrete maintenance task. Applications embedding Siddhi should identify which `siddhi-*` modules they use and test query compilation and event processing across version changes. Teams using the microservice form must separately track runtime distribution and integration dependencies. The README names community support channels but does not promise response times or long-term support for every module.

Editorial conclusion

Adopt Siddhi Core Libraries when an application needs to embed Streaming SQL and complex event detection, especially if Java or Python integration is important. Do not treat this repository as a standalone runtime distribution, because it contains core modules and points to separate tooling and runtime downloads. Verify the compatible 5.x artifact, deployment form, required extensions, and the API documentation version before integration. For a project already standardized on another embedded query engine, the first check should be whether Streaming SQL syntax and windowing requirements map cleanly to Siddhi's execution model.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. siddhi-io/siddhi on GitHub