Hi Isaeed, Thank you, this is very helpful.
The distinction between the two cases makes sense: 1. large Cassandra tables where Elasticsearch is justified because broad search is required 2. smaller relational-style tables where maintaining extra Cassandra query/index tables creates overhead, but maintaining a separate Elasticsearch path may not be worth it The “correctness and support” point is probably the key one. I agree that an integrated indexing layer would only be useful if it has clear failure semantics, deterministic rebuild, bounded indexing delay, and a supportable operational model. One clarification from my side: the direction I’m exploring is closer to Cassandra-native search indexing with OpenSearch compatibility. Since you mentioned Elasticsearch specifically, I would need to be careful about compatibility claims because OpenSearch and Elasticsearch have diverged over time. What Elasticsearch version are you running? Thanks again, Maxim On Sun, Jul 19, 2026 at 11:06 Isaeed Mohanna <[email protected]> wrote: > 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 >
