A ordenação por PK de incremento automático garante a ordem cronológica?

Assumindo que "incremento automático" você quer dizer o SERIALpseudo-tipo Postgres , a resposta curta é "nem sempre".

SERIALas colunas são implementadas usando sequências SQL padrão, que podem gerar valores fora de ordem quando usadas por várias sessões simultâneas se o CACHEparâmetro for definido como algo maior que 1. O manual afirma o seguinte:

[A]embora seja garantido que várias sessões aloquem valores de sequência distintos, os valores podem ser gerados fora de sequência quando todas as sessões são consideradas. Por exemplo, com uma configuração de cache de 10, a sessão A pode reservar valores 1..10 e retornar nextval=1, então a sessão B pode reservar valores 11..20 e retornar nextval=11antes que a sessão A tenha gerado nextval=2. Assim, com uma configuração de cache de um, é seguro assumir que nextvalos valores são gerados sequencialmente; com uma configuração de cache maior que um, você deve apenas assumir que os nextvalvalores são todos distintos, não que eles sejam gerados puramente sequencialmente.

Deixar CACHEo valor em 1 pode prejudicar o desempenho em um ambiente com alta simultaneidade, então você terá que escolher o que é mais importante para você.

Na minha opinião, tentar redirecionar SERIALo rastreamento da ordem de criação de registros não é uma boa ideia, porque potencialmente cria um problema de manutenção: uma vez que a única promessa da sequência é fornecer algum valor de incremento exclusivo para cada nextvalsolicitação, contando com seu comportamento sob um circunstância pode fazer com que seu aplicativo se comporte de forma imprevisível quando a situação muda, por exemplo, os detalhes de implementação da sequência são modificados em uma versão futura do Postgres, ou mudanças em sua carga de trabalho exigem que você aumente a CACHEconfiguração. Usar um timestamp adequado para ordenação é mais seguro e semanticamente mais claro.

O que você entende por ordem cronológica?

Se houver uma transação 1 que começa antes da transação 2, mas termina após a transação 2, a primeira transação é a transação 1 ou a transação 2?

Se você estiver usando o SERIALIZABLEnível de isolamento de transações, ele garante que há uma ordem total para as transações: ou seja, há alguma ordem serial (não paralela) para as transações que daria o mesmo resultado das transações em execução no seu real sistema paralelo de vida.

Muito provavelmente, as sequências do PostgreSQL não fornecerão exatamente a mesma ordenação de valores do que a ordem total serializável. Você pode corrigir isso criando sua própria sequência: crie uma tabela com uma linha com uma coluna inteira e atualize essa linha. No entanto, se fizer isso, a paralelização de suas transações será prejudicada. Ele pode até sofrer de uma maneira que faz com que algumas das transações falhem.

Uma solução, conforme proposto por um comentário, são os carimbos de data/hora. No entanto, a ordem do carimbo de data/hora não é necessariamente a mesma que a ordem serial que daria os mesmos resultados.

(Como uma observação lateral, você deve estar preparado para transações com falha em todos os casos. Deadlocks causam transações com falha. O SERIALIZABLEnível de isolamento causa ainda mais transações com falha. A maneira correta é ter back-off exponencial e tentar novamente.)