Elassandra: Search and Cassandra Storage in One Distributed Database

Why Elassandra Combines Cassandra Storage and Elasticsearch Search

Elassandra addresses a specific operational problem: applications often need Cassandra's distributed storage model and Elasticsearch's search capabilities, but maintaining both systems can introduce duplicate documents, synchronization logic, and extra disk use. Elassandra is an Apache Cassandra distribution with Elasticsearch code embedded in its nodes. Cassandra remains the system of record, while changes to Cassandra data are indexed for search. According to the README, source documents can also remain in Cassandra, avoiding a second document store for indexed and non-indexed data.

The intended users are Cassandra teams that need full-text or spatial search, real-time aggregation, or searches spanning multiple keyspaces and tables. The README also presents Elassandra as relevant to Elasticsearch users who want masterless cluster state management through Cassandra lightweight transactions. Searches can use Elasticsearch facilities, including ingest processors that transform input data, and the project supports Elasticsearch plugins and products such as Kibana.

This is not a general-purpose replacement for every Cassandra deployment. Applications that do not need search may gain little from running Elasticsearch code inside each Cassandra node. Conversely, teams committed to Elasticsearch but unwilling to use Cassandra as the state and document store should not interpret Elassandra as a conventional side-by-side Elasticsearch cluster. Its central design choice is to bind the search layer to Cassandra's node, schema, replication, and administration model.

Elassandra Request Flow, Indexing, and Active-Active Storage

The architecture is visible in the README's description of embedded Elasticsearch code running inside Cassandra nodes. Cassandra holds both ordinary application data and Elasticsearch configuration state. Updates made through Cassandra are indexed in the embedded search engine, so full-text queries, spatial queries, aggregations, and REST requests can operate over data without a separate indexing service in the documented architecture.

The README says Elassandra supports Cassandra vnodes and that adding nodes allows horizontal scaling without resharding Elasticsearch indices. Writes are distributed across Cassandra nodes rather than being confined to one primary Elasticsearch shard. Adding Elassandra nodes is therefore presented as a way to increase read and write capacity. When a new node joins, only data pulled from existing nodes must be re-indexed, according to the project's documentation.

Cluster administration follows Cassandra rather than the usual Elasticsearch master arrangement. Elassandra is described as masterless, with cluster state managed through Cassandra lightweight transactions. Elasticsearch shards remain master-slave constructs inside that broader system, but Cassandra distributes writes across all nodes in a virtual datacenter. This distinction matters operationally: administrators still need to reason about both Elasticsearch routing state and Cassandra replication when diagnosing availability or consistency.

For multiple datacenters, the README describes active/active replication and local writes with global search. It also attributes hinted handoff, read repair, and `nodetool repair` support to Cassandra. These are Cassandra mechanisms, not promises that Elasticsearch itself supplies cross-region coordination.

Starting a Single-Node Elassandra Cluster Through the Project Documentation

The README does not contain a self-contained Docker command, configuration file, or first-query example. It directs new users to the Quick Start guide at `http://doc.elassandra.io/en/latest/quickstart.html`, which it describes as the procedure for running a single-node Elassandra cluster in Docker. Because those operational steps are not included in the repository text available here, this review does not reproduce or guess them.

A first real evaluation should follow that linked guide until the single node is available, then use the project's JSON REST access to create or load Cassandra data and submit a search covering the indexed field. The repository establishes that both JSON REST access to Cassandra data and automatic schema creation exist, but it does not state the endpoint, request payload, index mapping, or expected response in the README. Those details must be taken from `doc.elassandra.io` rather than inferred from generic Elasticsearch conventions.

For a wider deployment, the repository also links to a Google Kubernetes Engine tutorial under `docs/google-kubernetes-tutorial.md`. That path demonstrates an intended Kubernetes deployment route, but the README excerpt does not provide its manifests or commands. There is therefore no justified shell transcript to include. A reader who needs a reproducible first session should treat the official Quick Start page as a required source rather than assuming that the repository root alone is sufficient.

Elasticsearch Features Available Through the Cassandra Integration

Elassandra exposes a broader query surface than Cassandra's native table model. The README lists full-text and spatial search, real-time aggregation without Spark or Hadoop, and queries over multiple keyspaces and tables. It also supports nested documents through Cassandra User Defined Types and automatic creation of Elasticsearch schema. Those capabilities make Elassandra relevant when an application wants Elasticsearch query semantics while retaining CQL as its data model.

Document processing is not limited to direct retrieval. The embedded engine supports Elasticsearch ingest processors, allowing input data to be transformed before indexing. Compatibility with Elasticsearch plugins and Kibana is also stated, which may reduce the amount of separate search tooling an application needs. However, the README does not enumerate every compatible plugin version or spell out compatibility with current Kibana releases, so this should not be interpreted as version-independent integration.

Schema evolution receives special treatment because the search mappings are coupled to CQL. Elassandra manages concurrent Elasticsearch mapping changes and applies batched atomic CQL schema changes. Since Elassandra 6.2.3.8, the project documentation says Elasticsearch mappings are fully managed in the CQL schema. This coupling reduces synchronization work, but it also means Elasticsearch mappings cannot be changed as an isolated concern. Mapping updates rely on a Cassandra transaction requiring `QUORUM` nodes, an explicit operational constraint for large or degraded clusters.

Rolling-Upgrade Gates and Elassandra Replication-Factor Constraints

Elassandra upgrades require more care than replacing a standalone application package. For releases from 6.8.4.2 onward, the README describes optional compression of the gossip X1 application state. This setting can permit more virtual indices, but it must not be enabled until every 6.8.4.x node is first upgraded to 6.8.4.2 or higher. Nodes on that version can decompress the application state even before compression is configured locally. Administrators must then add `-Des.compress_x1=true` to `conf/jvm.options` and perform a rolling restart:

-Des.compress_x1=true

This sequence is bounded and should not be improvised. The earlier README section contains unresolved conflict markers, which is a quality warning for readers relying on the upgrade notes as their sole operational reference. The linked project documentation and version-specific instructions should be checked before a cluster change.

Elassandra 6.2.3.21 also changed how replication for `elasic_admin` and `elastic_admin_[datacenter.group]` is handled. Previously, it was automatically adjusted to the datacenter's node count. It is now the administrator's responsibility because automatic adjustment had a performance impact on large clusters. Since mapping updates depend on a `QUORUM` transaction, the README says replication factor should be at least 3 in each datacenter. This is a concrete capacity and failure-domain requirement that must be checked before rolling forward.

Metadata handling changed in 6.2.3.19. Mapping history moved from `elastic_admin.metadata` to `elastic_admin.metadata_log`, allowing recovery from a possible PAXOS write timeout. During a rolling upgrade from an affected earlier release, mapping updates must be stopped to avoid inconsistency. After all nodes are upgraded, the old table is described as unused and removable. These version gates make upgrade rehearsal part of adoption, not routine administration.

Maintenance Signals, License Boundaries, and a Separate Elasticsearch Deployment

The repository is not archived, and its last push was on 2026-05-17. That is a recent maintenance signal under the repository metadata, although the listed releases are older: v6.2.3.38 dated 2022-03-28, v6.2.3.37 dated 2022-03-22, and v6.8.4.16 dated 2022-01-04. The mismatch means prospective users should not assume that a recent commit establishes compatibility with current upstream Cassandra or Elasticsearch releases. The README does not document supported upstream ranges.

Elassandra is distributed under `Apache-2.0`. The repository includes `LICENSE.txt` and `NOTICE.txt`, so license obligations should be reviewed from those files along with any bundled dependency licenses under `licenses/`. This is a licensing note rather than legal advice. The presence of directories such as `modules/`, `plugins/`, `distribution/`, `client/`, and `server/` also indicates that adopting or building the distribution involves a substantial Java codebase rather than a single deployable script.

A real alternative is to run Apache Cassandra and Elasticsearch as separate systems, then build indexing and synchronization between them. Elassandra embeds the search engine, uses Cassandra for configuration and source documents, and distributes writes through Cassandra. A separate deployment gives Elasticsearch and Cassandra independent release and scaling choices, but it requires an indexing path and consistency design that Elassandra handles internally. Teams that require isolated failure domains, independent upgrade cadence, or conventional Elasticsearch operations should compare that added integration burden against Elassandra's single data-store model.

Editorial conclusion

Elassandra is a credible choice for engineering teams already using Cassandra that want search over existing tables without operating a separate Elasticsearch data store. It is a poor fit for teams seeking a lightweight current Elasticsearch distribution, independent search scaling, or an uncomplicated upgrade path. Before adoption, verify the Docker quick-start instructions in `doc.elassandra.io`, confirm that your Cassandra model and mapping changes fit the embedded integration, and review every required rolling-upgrade step for the target Elassandra version.

Frequently asked questions

Official sources

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