# Secondary indexes vs. denormalized tables

**URL:** <https://forum.scylladb.com/t/secondary-indexes-vs-denormalized-tables/2997>\
**Category:** ScyllaDB\
**Tags:** data-model, secondary-index, denormalization\
**Created:** [October 3, 2024, 5:23pm UTC](https://forum.scylladb.com/t/secondary-indexes-vs-denormalized-tables/2997 "2024-10-03T17:23:41Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![elyzk](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.scylladb.com/elyzk/32/1226_2.png) [@elyzk](https://forum.scylladb.com/u/elyzk)\
**Post date:** [October 3, 2024, 5:23pm UTC](https://forum.scylladb.com/t/secondary-indexes-vs-denormalized-tables/2997/1 "2024-10-03T17:23:41Z")

</div>

Hey. I’m writing a database that contains guilds and channels. Guilds can have multiple channels, but channel IDs are unique and each channel can only belong to a single guild. I want my channel table to be indexable by either channel ID or guild ID, because I will often want to find the guild that a given channel is part of.

If I establish guild ID as the primary key for my table and channel ID as a secondary index, Scylla will handle the creation of a reverse lookup table that maps channel ID → guild ID and then index the ‘channels’ table using its guild ID.

However, I could also create a custom denormalized table that does the same thing (maps channel ID → guild ID). Then, whenever I want to retrieve a channel by channel ID, I’ll query that table, retrieve the guild ID, and then index the original table by guild ID. This is prone to more errors because I will have to manually update the denormalized table whenever a channel is added/removed.

Are there any performance benefits to using a denormalized table vs. the built-in secondary index? I have read that denormalized tables are “more efficient for predefined, specific access patterns” but I don’t see how so. I assume that Scylla’s reverse lookup table and a custom denormalized table will have the same storage overhead.

---

<div class="post-metadata">

**Author:** ![felipemendes](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.scylladb.com/felipemendes/32/11_2.png) [@felipemendes](https://forum.scylladb.com/u/felipemendes)\
**Post date:** [October 4, 2024, 8:17pm UTC](https://forum.scylladb.com/t/secondary-indexes-vs-denormalized-tables/2997/2 "2024-10-04T20:17:08Z")

</div>

Views (thus indexes) updates are done asynchronously by the query coordinator. This - in turn - means that under rare circumstances the view update in question may fail and get inconsistent. You may overcome this with `synchronous_updates = true`, at the expense of more cycles to acknowledge a request back to your clients.

Denormalized tables allow for more efficient routing, at the expense of increased client-side complexity.

As you realized, both methods will work.