organização de tabelas com dados que nunca serão alterados

para referência, quase toda minha experiência de banco de dados é com mongodb e este é meu primeiro projeto postgres.

Estou armazenando atualizações de dados de pools de criptomoedas de finanças descentralizadas.

A estrutura de dados que estou explorando é muito simples. Existem fichas:

type Token =
    {
        Address:    string     // primary key
        Decimals:   int
        Symbol:     string
    }

Esses dados NUNCA serão alterados, mas são referenciados em todos os lugares; cerca de 2k entradas

type LiquidityToken =
    {
        Address:        string    // primary key
        Symbol:         string
        Token0Address:  string    // matches the address from a token above
        Token1Address:  string    // matches the address from a token above
        Timestamp:      DateTime  // changes at every update
        Token0Amount:   decimal   // changes at every update
        Token1Amount:   decimal   // changes at every update
    }

isso é atualizado a cada 5 minutos, no entanto, SOMENTE Token0Amount e Token1Amount mudam e eu quero manter um histórico.

Eu tenho aproximadamente 500 desses objetos com uma nova atualização a cada 5 minutos, então 140k novas entradas por dia.

então a primeira coisa que eu queria fazer é fazer uma junção entre os campos Token0/1Address e o registro Token, mas como o Token apenas adiciona um int e uma string curta (até 32 caracteres, mas geralmente < 8 caracteres), eu queria saber é que isso está economizando muito (não sei quanto espaço a junção está ocupando).

então eu queria saber se vale a pena dividir o objeto em duas partes:

type LiquidityToken =
    {
        Address:        string    // primary key
        Symbol:         string
        Token0Address:  string    // matches the address from a token above
        Token1Address:  string    // matches the address from a token above
    }

e

type LiquidityTokenUpdate =
    {
        Address:        string    // matches the address of the liquidity token 
        Timestamp:      DateTime  // changes at every update
        Token0Amount:   decimal   // changes at every update
        Token1Amount:   decimal   // changes at every update
    }

e apenas replicar este objeto. Mas agora uma consulta pode puxar a atualização, que puxa o token de liquidez que deve puxar 2 objetos de token.

Como isso é para uma interface pública do GraphQL, pode haver alguns padrões de uso que aparecerão. Não posso prever um tipo específico de consultas porque isso é algo que quero tornar público para a comunidade assim que estiver pronto.

Eu entendo que o cache é meu amigo aqui e como os dados estáticos são pequenos cabe tudo na RAM, mas no geral faria sentido tentar economizar espaço (cada registro não é muito grande) e adicionar o custo das junções ou pesquisa no cache local, ou é melhor apenas salvar tudo a cada atualização, já que o disco é barato?

Por favor, coloque no contexto que isso não é algo que eu tenha experiência; Eu li sobre junções, normalização vs desnormalização de tabelas, etc, mas não tenho experiência prática com isso. Eu lidei com conjuntos de dados muito grandes, mas em um contexto não SQL e esta é minha primeira vez aqui, então espero que a pergunta forneça as informações necessárias: D