Lance diz ser até 100x mais rápido que o Parquet em workloads de IA

O ponto de partida é o layout do Parquet. Ele organiza os dados em row groups, depois em chunks de coluna e páginas. A página é a menor unidade de leitura. Para buscar uma linha, o engine lê a página inteira, descomprime e decodifica tudo até chegar ao valor. Quanto maior a página, maior a latência no acesso aleatório.

Há mais dois gargalos. O FileMetadata do rodapé usa Thrift ou Protocol Buffers, então o leitor desserializa o objeto inteiro mesmo para ler o schema de uma coluna só. Com tabelas de machine learning que chegam a 10.000 colunas, isso pesa. Além disso, o writer precisa bufferizar o row group inteiro na memória, o que causa OOM com embeddings grandes. Com valores de 4 KiB e row group de 512 MB, sobram só 125.000 linhas por grupo, e todas as colunas ficam presas a esse limite. O resultado são muitos row groups pequenos, mais metadados, mais leituras não adjacentes, mais requisições GET no object storage e compressão pior.

O Lance, lançado por volta de 2022 pela LanceDB, abandona o row group. Cada coluna tem páginas de 8 MB por padrão, localizadas por offset absoluto, e o número de páginas segue o tamanho dos dados. Para valores pequenos, usa mini-block (chunks de 4 a 8 KiB, até 4.096 valores). Para valores de 256 bytes ou mais, usa full-zip, que intercala metadado e dado e só aceita encodings transparentes, ou seja, dá para decodificar um valor sem os vizinhos. Cada coluna tem sua própria mensagem protobuf de metadados, então o acesso ao schema de uma coluna não exige decodificar as outras. A afirmação de 100x mais rápido vem do formato para acesso aleatório, e o autor do texto não tem vínculo com nenhuma organização.

A cobertura anterior toca o tema, mas não mostra evolução do Lance em si. Em 21 de maio de 2026, o CEVIU noticiou "O que os benchmarks de agentes de dados nos dizem e o que não dizem", citando o Lance entre os novos sistemas que aproximam dados e IA. Agora o foco é técnico: por que o layout do Parquet limita o acesso aleatório e como o Lance muda isso. Em 22 de outubro de 2026, o texto "Do disco à memória colunar: o que o Apache Arrow resolve que o Parquet não resolve" já tratava de outra limitação do Parquet, a análise em memória.

Para quem opera pipelines de dados que alimentam busca semântica ou treino, a leitura é que o formato de arquivo vira decisão de arquitetura. Se o padrão de acesso é recuperar poucas linhas de embeddings, otimizar só para scan pode custar latência e memória. Para workloads puramente analíticas, o Parquet segue adequado, e o ganho de 100x deve ser validado no seu caso de uso.