Can I Safely Use Aliases if My Application Requires a Single Fixed Index Name for All Operations?

Elastic Stack Elasticsearch
1

Hello everyone,

I’m looking for some guidance on an aliasing challenge I’m running into.

We’re using an in-house Java-based application as the frontend to our Elasticsearch cluster. I’ve been exploring index aliases to keep index sizes manageable and improve query performance. However, during testing we discovered that the application has a hard dependency on one static index name for all operations:

  • It writes only to one specific index name

  • It reads/searches only from that same index

  • It updates documents using that same fixed index name (the index name is included in every update request)

At the same time, we also need to support updating existing ingested documents, which usually requires knowing exactly which physical index a document resides in.

Given these constraints:

Is it still possible to use aliases effectively?

Or does the application’s requirement for a single, fixed index name make write aliases or rollover strategies impractical without modifying the application?

Below is a simplified example of what I’m attempting:

# Physical index
PUT my_app_index-000001

# Alias used by the application
POST _aliases
{
  "actions": [
    {
      "add": {
        "index": "my_app_index-000001",
        "alias": "my_app_index",
        "is_write_index": true
      }
    }
  ]
}

Any guidance or recommendations would be greatly appreciated.

Thank you,
Mike W.

2

You can only index/update/delete against aliases that only point to a single index. You would therefore need to modify the application in order to hide multiple indices behind an alias.

3

Thank you, Christian for the clarification that indexing/updating/deleting can only be performed against an alias when it points to exactly one backing index.

I’d like to refine my question based on that info.

We are using an in-house Java-based application that has a hard-coded dependency on a single, static index name for all operations:

  • Writes only to one specific index

  • Reads/searches only from that same index

  • Updates documents using that same fixed index name

During testing, we confirmed that the index name is always included in update requests, so the application cannot target multiple physical indices.

At the same time, my DEV staff needs the ability to update previously ingested records, including documents that now reside in older indices (e.g., my_app_index-000001 while the alias now points to my_app_index-000002).

Given that:

  • The app can only write/update through a name that maps to a single physical index

  • DEV occasionally needs to update historical documents stored in earlier indices

Is there any aliasing pattern that can safely support this?

Or does this fully confirm that:

  • Write aliases and rollover remain impossible without modifying the application, and

  • Updating older records would require addressing their physical index names directly?

Thank you,
Mike W.

4

If you can not change the application or add the logic to some custom proxy layer you will as far as I can see need to use a single backing index.

Correct.

Yes, that is generally correct. You might be able to use update-by-query, but that can be inefficient and possibly add a whole different set of problems/issues/limitations.

Another way to handle this may be to create a process to increase the number of primary shards for indices that get too large using the split index API. In order to do this you would create an alias that is used by the application and that points to a single backing index. This allows you to make changes to backing indices while quickly pointing the application to the correct one. When increasing the number of primary shards the index would need to be made read-only for a likely small amount of time while the API is called. Once the new index is created you ensure this new index is writeable and point the alias to this before deleting the original one. The alias at any time only points to a single index so you would need to remove the alias from the old index in the same call as wehere you add it to the new one.

Might this be an option?

5

I will definitely worth a try . Thanks