I am attaching a code, for the sake of reference. Combing through different resources. To come up with possible answer.

action

    read :read do
      primary? true
      pagination offset?: true, default_limit: 10
      argument :check_cache, :boolean do
        default true
      end
      prepare Preparations.CheckCache
    end

defmodule Preparations.CheckCache do
  @moduledoc """
  Checks a simple agent cache for libraries
  """
  use Ash.Resource.Preparation

  def prepare(query, _, _) when query.arguments.check_cache == true do
    CacheHelper.attach_cache(query)
  end

  def prepare(query, _, _) do
    query
  end
end

  def attach_cache(%Ash.Query{} = query) do
    query
    |> before_action()
    |> Ash.Query.after_action(fn query, records -> after_action(query, records) end)
  end

  def before_action(%Ash.Query{} = query) do
    cache_name = ReserveCache.name()

    key = query_filter_to_key(query)
    # take arguments to key as well

    updated_query =
      case Cachex.exists?(cache_name, key) do
        {:ok, true} ->
          {:ok, results} = Cachex.get(cache_name, key)
          Ash.Query.set_result(query, results)

        _ ->
          query
      end

    updated_query
  end

Every extra layer adds complexity and caching is one of those layers that tend to become complex. Most databases can be tweaked to cache more (they already do, but default settings are generally quite low) and if tweaking is enough, the complexity is completely handled by the database. Let the database do the heavy lifting for you (also research ‘materialized tables’)

That being said: let’s continue with the original question below.

Well I guess the first question is to ask whether you have a measured performance issue or are just assuming that there will be one?

Postgres is pretty damn good at planning and executing queries efficiently so I’d probably start by analysing the queries that Ash is generating to make sure that the appropriate indexes are in place and being utilised. Second if Ash is generating a pathological query I’d open an issue on the ash_postgres repo to see if it can be made more efficient. Only after I had exhausted the “just use the database” options would I seriously consider the complexity of caching or denormalising the data.

If the data is very fast moving then I might start considering my options re keeping some of it in RAM; caching is one method, the other is an ETS backed resource that works like a read through cache or is populated by changes to the underlying resource.

Otherwise, given that storage is usually cheaper and more abundant than memory I would consider denormalising the data into a JSON attribute somewhere and using that for reads. Probably populated by after action hooks or background jobs.