Hi 1. Elastic Search for specific large tables that require extended search functionality. 2. The complexity, the update is done in the application layer itself to both DB and index, therefore we try to avoid using it only for very few tables that is a must. 3. Tolerable as long is its within several seconds. 4. Yes it would, especially for tables that has relations and we are forced to create multiple index tables in cassandra to answer our queries, which is an overhead. 5. Correctness and support
In general we see two patterns, the first is tables that has millions of records and still require search in almost all of its fields, which is where we use elastic, and the effort might be justified The second pattern is small tables, smaller than a million records (sometimes only thousands) that has relations with other small tables, so its not only search but also joins, those are pain to maintain in cassandra and the effort to maintain in ES is not worth it, so an integrated index will help with those to eliminate the need of maintaining an index table. Regards ________________________________ From: Maxim T <[email protected]> Sent: Sunday, July 5, 2026 11:44 AM To: [email protected] <[email protected]> Subject: Validating Cassandra → OpenSearch indexing pain Hi all, I’m validating an approach around Cassandra-native OpenSearch indexing. The use case is teams that keep Cassandra as the source of truth but also need search/query patterns that Cassandra does not support well. Today this is usually handled through CDC, Kafka, custom dual-writes, Spark jobs, periodic backfills, or some other external indexing path into OpenSearch/Elasticsearch. The problem I’m looking at is operational rather than theoretical: * indexing lag * missed or duplicated updates * reindexing/backfill complexity * consistency drift between Cassandra and the search layer * recovery after failed consumers or partial writes * operational burden of running the sync pipeline I’m trying to understand whether this is a serious production pain for Cassandra users, or whether most teams are satisfied with external indexing pipelines. For teams running Cassandra with OpenSearch or Elasticsearch downstream: 1. What architecture are you using today? 2. Where does the indexing path fail in practice? 3. Is search freshness/consistency business-critical or just a tolerable limitation? 4. Would a tighter Cassandra-integrated indexing layer be interesting, or would that create too much operational risk? 5. What benchmark, failure-mode test, or compatibility proof would make you willing to evaluate an alternative? I’m looking for blunt technical feedback before overbuilding anything. Thanks, Maxim
