Materialidade Física em Bancos de Dados Relacionais: da Consulta SQL ao Consumo Energético

1. Introdução

A execução de uma consulta como SELECT * FROM users WHERE id = 42 é, para quem desenvolve sistemas de informação, um evento tão frequente que deixou de ser percebido como um evento: solicita-se um valor e ele retorna, tipicamente em milissegundos, sem que a operação pareça exigir explicação adicional. Esse caráter aparentemente transparente da consulta é o objeto deste artigo. A pergunta que o orienta não é o que a consulta significa, no sentido lógico que a literatura de bancos de dados já explica com precisão, mas onde e de que modo o valor por ela retornado existe fisicamente entre o momento em que é solicitado e o momento em que aparece na tela de quem o solicitou.

Essa pergunta tem uma tradição de resposta técnica bem estabelecida. A partir da proposta de Codd (1970) de descrever dados exclusivamente por sua estrutura lógica — a que o autor chamou independência de dados —, a arquitetura de sistemas de gerenciamento de bancos de dados relacionais consolidou uma separação explícita entre o esquema lógico que o usuário manipula e a representação física que o sistema mantém em memória e em armazenamento persistente. O Grupo de Estudos ANSI/X3/SPARC (1975) formalizou essa separação em uma arquitetura de três esquemas — externo, conceitual e interno —, hoje difundida como princípio de design, ainda que jamais plenamente implementada como especificação formal por nenhum sistema dominante. Essa tradição técnica descreve com grande detalhe os mecanismos internos de um sistema de gerenciamento de banco de dados — controle de concorrência multiversão, registro de escrita antecipada, estruturas de indexação em árvore — mas raramente conecta esses mecanismos a uma discussão mais ampla sobre a materialidade física da informação e seus custos ambientais.

Uma segunda tradição, oriunda dos estudos de mídia e de infraestrutura, trata exatamente dessa materialidade, mas em um grão de análise mais amplo. Blanchette (2011) argumenta que bits não podem existir fora de instanciações materiais específicas, e que a computação constitui, de ponta a ponta, um processo material. Kirschenbaum (2008) refina essa posição ao distinguir a materialidade forense de um traço físico específico da materialidade formal de um sistema simbólico que se comporta de modo consistente independentemente de qual suporte físico o realiza. No nível da infraestrutura, Star (1999) descreve como sistemas de infraestrutura tendem a ser transparentes ao uso, tornando-se visíveis apenas quando falham, e Hu (2015) historiciza a metáfora da nuvem computacional, associando-a a uma genealogia de redes de infraestrutura muito mais antigas. Gonzalez Monserrate (2022), a partir de pesquisa etnográfica em data centers, argumenta que os custos ambientais da computação em nuvem são obscurecidos pela complexidade das próprias infraestruturas e cadeias de suprimento envolvidas.

O problema de pesquisa deste artigo situa-se exatamente na lacuna entre essas duas tradições. A literatura de sistemas descreve o mecanismo sem a materialidade; a literatura de materialidade descreve a infraestrutura sem o mecanismo interno de um sistema de gerenciamento de banco de dados especificamente. Falta, entre as duas, uma análise que utilize a arquitetura interna de um sistema relacional — não a infraestrutura de rede ou de data center isoladamente — como ponto de ancoragem técnico para uma discussão de materialidade e de custo ambiental. Essa lacuna importa porque sistemas de gerenciamento de bancos de dados relacionais permanecem, décadas após sua proposição original, componente central da maior parte da infraestrutura de armazenamento de dados em uso corrente, incluindo a infraestrutura de computação em nuvem.

A contribuição deste artigo é ocupar esse espaço intermediário: partir de uma única instrução de consulta e descer, camada por camada, da sintaxe ao estado físico que a sustenta, examinando em cada camada se a exigência observada decorre de necessidade lógica, de convenção de uma implementação específica, ou de escolha de engenharia contingente. A partir dessa descida, o artigo acompanha as consequências materiais dessa arquitetura até seus custos energéticos e ambientais, com o cuidado explícito de distinguir limites físicos teóricos de custos reais determinados por eficiência de engenharia. O objetivo geral é, portanto, examinar de que modo a arquitetura em camadas de sistemas de gerenciamento de bancos de dados relacionais reconfigura a relação entre a instanciação física da informação e sua manipulação simbólica, e em que medida essa reconfiguração torna sistematicamente menos visíveis os custos materiais dessa instanciação.

2. Materiais e métodos

Trata-se de pesquisa de natureza qualitativa e interdisciplinar, que combina três componentes metodológicos complementares: análise conceitual, revisão de literatura e análise técnica documental com proposta de verificação empírica reproduzível.

O primeiro componente consiste na decomposição da cadeia de camadas entre a sintaxe de uma consulta e seu estado físico final em proposições examinadas individualmente quanto ao seu estatuto lógico — se decorrem de necessidade conceitual, de convenção amplamente adotada, ou de escolha de engenharia específica de uma implementação —, seguindo o princípio metodológico de que essas três categorias não devem ser tratadas como equivalentes em uma discussão tecnicamente rigorosa.

O segundo componente é a revisão de literatura, que reúne fontes de três eixos temáticos correlacionados aos objetivos específicos da pesquisa: (i) literatura fundadora e de arquitetura de sistemas de bancos de dados, para estabelecer a base técnica da independência entre representação lógica e física; (ii) literatura de estudos de mídia, infraestrutura e materialidade da informação, para fundamentar a discussão conceitual central; e (iii) literatura e documentação institucional sobre eficiência energética e impacto ambiental de infraestrutura computacional, para embasar a discussão final sobre consequências materiais.

O terceiro componente é a análise técnica documental, que utiliza documentação oficial de sistemas de gerenciamento de bancos de dados relacionais de código aberto e proprietários — especificamente PostgreSQL, MySQL/InnoDB, SQL Server e SQLite — como fonte primária para descrever mecanismos de armazenamento, indexação e controle de concorrência, sem generalizar comportamento específico de uma implementação como propriedade universal de sistemas relacionais. A esse componente soma-se um protocolo de verificação empírica reproduzível, especificado no Quadro 2, que descreve procedimentos técnicos executáveis — inspeção de página física por meio das ferramentas pageinspect e sys.dm_db_page_info, inspeção de registro de escrita antecipada por meio de pg_waldump, e medição exploratória de consumo energético por meio de contadores de processador — cuja execução e cujos resultados específicos permanecem como etapa complementar de validação empírica a este artigo, não incorporada em sua versão atual.

A análise dos resultados obtidos por esses três componentes é conduzida por confronto direto com a literatura revisada na fundamentação teórica, buscando estabelecer, para cada camada examinada, seu grau de necessidade e sua conexão com a discussão de materialidade e de sustentabilidade computacional.

3. Fundamentação teórica

3.1 Independência de dados e o modelo relacional

Antes de 1970, sistemas de gerenciamento de dados organizados segundo os modelos hierárquico e em rede exigiam que o programa de aplicação conhecesse, de forma íntima, a organização física dos registros: a ordem em que apareciam, os ponteiros que os associavam a registros pais e filhos, e o caminho de acesso necessário para localizá-los. Reorganizar o armazenamento físico — trocar um índice, redistribuir arquivos, otimizar o layout de dados — implicava, com frequência, reescrever o programa que dele dependia, de modo que estrutura lógica e estrutura física constituíam, na prática, a mesma coisa observada por ângulos distintos.

Codd (1970), pesquisador da IBM, propôs uma reformulação desse problema utilizando a noção matemática de relação. O argumento central do autor não é que tabelas sejam uma metáfora conveniente, mas que dados possam ser descritos exclusivamente por sua estrutura lógica natural, sem carregar informação sobre como estão armazenados, ordenados ou indexados. A essa propriedade o autor chamou independência de dados, definida como a independência dos programas de aplicação e das atividades de terminal em relação ao crescimento dos tipos de dados e a mudanças na representação física dos dados. Um programa que consulta a linha em que id = 42 não precisa saber, sob esse princípio, se essa linha está organizada em uma árvore B, em um arquivo sequencial ordenado, ou distribuída entre diferentes dispositivos de armazenamento.

O Grupo de Estudos ANSI/X3/SPARC (1975) formalizou essa separação em uma arquitetura de três esquemas — externo, conceitual e interno —, isolando a visão que cada usuário tem dos dados, o modelo lógico compartilhado por todo o sistema, e os detalhes de armazenamento físico propriamente dito. É necessário registrar, contudo, uma ressalva historiográfica: essa arquitetura nunca se tornou uma especificação formal plenamente implementada — nenhum sistema de gerenciamento de banco de dados dominante isola de modo completo esses três níveis, e todos expõem, em algum grau, decisões de armazenamento a quem otimiza consultas com profundidade suficiente. O que se difundiu amplamente não foi o desenho técnico exato da arquitetura de três esquemas, mas o princípio de independência lógico-física que a sustenta, hoje presente, em graus variados, em praticamente qualquer sistema que separa o que se pergunta de como a pergunta é respondida.

Cabe ainda observar que a ascensão da linguagem de consulta estruturada (SQL, do inglês Structured Query Language) à condição de padrão de fato não decorreu de superioridade técnica isolada. A linguagem foi padronizada pelas organizações ANSI e ISO, adotada comercialmente pela IBM e, de forma decisiva, pela Oracle, e beneficiou-se de efeitos de rede que qualquer tecnologia dominante acumula à medida que ferramentas, literatura técnica e profissionais treinados se concentram em torno dela. Essa observação é relevante porque a sequência histórica que conduz dos modelos hierárquico e em rede ao modelo relacional, à linguagem de consulta estruturada e à computação em nuvem contemporânea é, por vezes, apresentada como uma progressão linear de aperfeiçoamento técnico contínuo — leitura que este artigo considera imprecisa. O movimento denominado NoSQL, que ganhou tração a partir dos anos 2000 com sistemas orientados a documentos, a pares chave-valor e a grafos, constitui evidência de que o modelo relacional, para determinadas classes de problema — escala horizontal massiva, esquemas de dados voláteis, dados profundamente hierárquicos —, impõe restrições reais, não apenas hipotéticas. A posição central do modelo relacional deve ser compreendida como contextual a uma classe extensa de problemas, não como universal ou definitiva. A Figura 1 sintetiza essa trajetória histórica de modo não linear, indicando os pontos em que alternativas concorrentes se ramificam em vez de sucederem umas às outras.

3.2 Materialidade da informação

A independência de dados descrita na seção anterior é uma conquista de engenharia, não uma eliminação da física subjacente à informação. Blanchette (2011) enfrenta diretamente essa questão ao contestar a caracterização — recorrente tanto na imprensa quanto em parte da literatura acadêmica — da informação digital como fundamentalmente imaterial, independente do meio físico específico que a armazena. Segundo o autor, essa caracterização, embora intuitivamente atraente, é problemática: bits não podem existir fora de instanciações em formas materiais, e sistemas computacionais são, em todos os seus níveis, atravessados por restrições de materialidade. A tese central de Blanchette (2011) — de que a computação constitui um processo material de ponta a ponta — converge com o argumento arquitetural da seção 3.1: a independência de dados não suprime a materialidade da informação, apenas a desloca para um nível da arquitetura ao qual a maior parte de quem escreve consultas não precisa atender.

Kirschenbaum (2008) oferece uma ferramenta conceitual adicional relevante para esse argumento, ao distinguir dois sentidos de materialidade aplicáveis a objetos digitais. A materialidade forense refere-se ao traço físico específico e irrepetível de uma inscrição particular — nenhuma marca física é idêntica a outra, mesmo quando corresponde ao mesmo valor lógico. A materialidade formal refere-se ao comportamento sistemático do sistema simbólico que permite reprodução confiável de um valor, abstraindo as particularidades físicas de cada instanciação. O autor denomina ideologia medial a tendência de interpretar o evento digital exibido em uma tela como se existisse independentemente do mecanismo tecnológico específico que o sustenta — uma tendência que a arquitetura em camadas descrita na seção 3.1, por motivos primariamente técnicos, torna mais fácil de adotar, ainda que não a torne inevitável.

Desses dois argumentos decorre uma distinção metodológica que este artigo adota de modo consistente: a exigência de que toda informação, para existir operacionalmente em um sistema computacional, dependa de algum suporte físico é próxima de uma necessidade conceitual, dado o que se entende por operação como ação causal; mas qual suporte físico específico realiza essa exigência — transistores eletrônicos, memória flash, fibra óptica — constitui contingência tecnológica; e a arquitetura específica que uma implementação constrói sobre essa contingência — o modelo relacional, a linguagem de consulta estruturada, a virtualização — constitui, por sua vez, escolha de engenharia histórica e comercialmente situada. A confusão entre esses três níveis é, na avaliação deste artigo, a principal fonte de imprecisão em discussões públicas e acadêmicas sobre a materialidade dos dados.

3.3 Infraestrutura e transparência ao uso

Star (1999) propõe uma abordagem etnográfica ao estudo de infraestruturas, definindo-as, entre outras propriedades, como sistemas relacionais e ecológicos que se tornam transparentes ao uso — isto é, que sustentam tarefas rotineiras sem exigir reinvenção constante — e que só se tornam visíveis para quem os utiliza no momento em que falham. Essa propriedade aplica-se com precisão à arquitetura de bancos de dados relacionais descrita na seção 3.1: a independência de dados é, precisamente, o mecanismo que torna a infraestrutura de armazenamento transparente ao uso, permitindo que uma consulta seja escrita sem atenção à sua materialização física, exceto quando essa materialização falha ou se degrada.

Hu (2015) acrescenta a essa análise uma dimensão histórica específica à computação em nuvem. O autor demonstra que a metáfora da nuvem computacional herda, de redes de infraestrutura muito mais antigas — ferroviárias, de saneamento, de telecomunicações —, tanto seu vocabulário quanto parte de sua genealogia institucional, incluindo instalações militares da Guerra Fria posteriormente reconvertidas em centros de dados. O argumento de Hu (2015) não é meramente histórico: o autor sustenta que a metáfora da nuvem, ao associar-se a uma conotação de leveza e ausência de lugar, torna mais fácil ignorar uma infraestrutura concentrada geograficamente e, em sua origem, associada a lógicas de poder e vigilância. Essa observação é relevante para a seção 4.4 deste artigo, na qual se examina em que sentido a computação em nuvem reorganiza, mais do que elimina, a infraestrutura física subjacente ao armazenamento de dados.

3.4 Termodinâmica da computação

Landauer (1961), então pesquisador da IBM, demonstrou que apagar um bit de informação — operação logicamente irreversível, no sentido de que o estado anterior não pode ser reconstruído a partir do estado seguinte — dissipa, no mínimo, uma quantidade de energia equivalente a kT ln 2, em que k corresponde à constante de Boltzmann e T à temperatura absoluta do sistema. Três décadas depois, Landauer (1991) consolidaria essa posição na afirmação de que a informação é física: não porque seja composta de átomos, mas porque processá-la — armazená-la, apagá-la, transmiti-la — constitui sempre um processo físico, sujeito às mesmas leis que regem qualquer outro processo físico, a começar pela segunda lei da termodinâmica. Bennett e Landauer (1985) reforçam essa posição ao discutir os limites físicos fundamentais da computação como um problema tratável quantitativamente, e não apenas como metáfora.

Esse limite é, à temperatura ambiente, extremamente pequeno — da ordem de poucos zeptojoules por bit apagado, aproximadamente vinte e duas ordens de grandeza menor do que as quantidades de energia dissipadas rotineiramente em escala macroscópica. A distância entre esse piso teórico e o consumo energético real de hardware contemporâneo é, para os fins deste artigo, tão relevante quanto o próprio limite: a energia de comutação de um transistor em tecnologia CMOS está projetada para se aproximar do limite de Landauer apenas por volta de 2035, o que indica que a engenharia de hardware atual opera, na prática, muitas ordens de grandeza acima desse piso. Essa distância implica que o consumo energético real de uma operação computacional é determinado, hoje, por ineficiências de engenharia contingentes — padrões de acesso à memória, eficiência de refrigeração, escolhas de provisionamento — e não pela física fundamental da informação. Esse é um ponto metodológico central para a seção 4.5 deste artigo: qualquer discussão de custo ambiental da computação que invoque o limite de Landauer como se fosse uma estimativa de consumo real estaria conflando níveis de análise incompatíveis.

3.5 Nuvem, responsabilidade e impacto ambiental

A computação em nuvem introduz uma reorganização adicional sobre a arquitetura descrita nas seções anteriores, que não se limita à dimensão técnica. Provedores de infraestrutura de nuvem documentam essa reorganização por meio do que costumam denominar modelo de responsabilidade compartilhada, segundo o qual o provedor responde pela segurança da infraestrutura física, da virtualização e das instalações — e o cliente responde pela configuração, pelos dados e pelo controle de acesso —, em uma fronteira que se desloca conforme o serviço contratado corresponda a infraestrutura básica ou a um banco de dados totalmente gerenciado (AMAZON WEB SERVICES, [2024]). Essa reorganização evidencia que a computação em nuvem não elimina a infraestrutura física subjacente ao armazenamento de dados; reorganiza sua administração e a distribuição de responsabilidade sobre cada camada.

O custo energético dessa infraestrutura é mensurado, na prática de operação de data centers, pela métrica de eficiência de uso de energia — do inglês power usage effectiveness, ou PUE —, definida como a razão entre a energia total consumida por uma instalação e a energia que efetivamente chega ao equipamento de computação, sendo o restante consumido por refrigeração, conversão de energia e perdas de distribuição (THE GREEN GRID, 2012). Um valor de PUE igual a 2,0 significa que, para cada unidade de energia consumida pelos servidores, outra unidade inteira é consumida apenas para manter a temperatura de operação adequada. Gonzalez Monserrate (2022), com base em pesquisa etnográfica realizada em data centers, argumenta que os custos ambientais dessa infraestrutura — consumo de água para refrigeração, extração de matérias-primas para fabricação de equipamentos, geração de lixo eletrônico decorrente de ciclos curtos de substituição de hardware — tendem a permanecer obscurecidos pela complexidade das próprias infraestruturas e cadeias de suprimento envolvidas, complexidade que, argumenta este artigo, é estruturalmente correlata à arquitetura de independência lógico-física discutida na seção 3.1.

4. Resultados e discussão

4.1 Da sintaxe à representação física

Quando um cliente envia a instrução SELECT * FROM users WHERE id = 42 a um sistema de gerenciamento de banco de dados, o texto atravessa, antes de significar qualquer coisa, um protocolo de rede próprio do sistema — uma sequência de mensagens binárias sem relação sintática direta com a linguagem de consulta estruturada. Do lado do servidor, um processo recebe essa sequência, reconstrói o texto da consulta e o submete a um analisador sintático, que verifica sua conformidade gramatical e produz uma árvore de análise. Essa árvore é submetida a análise semântica, que confere a existência dos identificadores referenciados no esquema e resolve tipos e permissões, e, por fim, chega a um otimizador de consultas, cuja função é decidir como executar uma operação que a linguagem declarativa especifica apenas quanto ao que deve ser executado.

Esse é o primeiro ponto em que a promessa da linguagem declarativa se revela parcial: a linguagem de consulta estruturada não determina como uma linha deve ser localizada, apenas qual linha deve ser retornada. O otimizador de consultas decide, com base em estatísticas sobre a tabela — número de linhas, seletividade da condição de busca, existência de índices sobre a coluna referenciada —, se é mais eficiente percorrer sequencialmente todas as linhas da tabela ou utilizar uma estrutura auxiliar, tipicamente uma árvore B ou B+, que mapeia valores de uma coluna a localizações físicas das linhas correspondentes. O resultado dessa decisão constitui um plano de execução: uma sequência concreta de operações físicas que, uma vez seguida, produz o resultado logicamente correto.

Supondo que o plano de execução utilize o índice, a árvore B devolve não a linha propriamente dita, mas um endereço físico — no caso do PostgreSQL, um identificador de tupla (tuple identifier, ou TID), composto por número de página e posição dentro da página. Nesse ponto, a noção de linha deve ser substituída por um vocabulário mais preciso: o que existe fisicamente não é uma linha, mas uma tupla — uma sequência de bytes com um cabeçalho que registra, entre outras informações, dados de controle de concorrência sobre o intervalo de validade daquela versão específica da tupla, seguida por um mapa de bits indicando quais colunas contêm valores nulos e pelos próprios valores, cada um convertido de um tipo lógico para sua representação binária. O valor numérico 42 buscado pela consulta corresponde, nesse nível, a uma sequência fixa de bytes em posição determinada dentro dessa estrutura, não mais a um numeral no sentido em que a sintaxe da consulta o apresenta.

A tupla, por sua vez, reside dentro de uma página — no PostgreSQL, por padrão, de oito quilobytes —, unidade mínima de leitura e escrita para o sistema de armazenamento: não existe operação de entrada e saída menor que uma página inteira, de modo que a leitura de um único inteiro de quatro bytes implica, na prática, a movimentação de toda a página que o contém. Antes de qualquer leitura física de armazenamento, o sistema verifica se a página solicitada já se encontra em uma região de memória compartilhada mantida pelo próprio sistema de gerenciamento — denominada shared_buffers no PostgreSQL —, e, abaixo dessa camada, tipicamente existe ainda uma segunda camada de cache mantida pelo sistema operacional, sobre a qual o sistema de gerenciamento de banco de dados não exerce controle direto (POSTGRESQL GLOBAL DEVELOPMENT GROUP, [2024]). O efeito é que a mesma página pode existir, em um dado instante, simultaneamente em mais de uma região de memória volátil, além de sua versão persistida em armazenamento — fenômeno de multiplicidade física retomado com maior detalhe na seção 4.2.

No nível do armazenamento persistente, um dispositivo de estado sólido não grava bytes individuais: grava, e sobretudo apaga, em unidades de bloco que agrupam múltiplas páginas físicas de memória flash do tipo NAND. Cada célula armazena informação como uma quantidade de carga elétrica retida em uma porta flutuante, cuja tensão de limiar, lida por um circuito sensor, é interpretada como um ou mais bits segundo convenção estabelecida pelo fabricante. Essa carga não é permanente — dissipa-se lentamente, e ciclos repetidos de escrita degradam fisicamente o material isolante —, razão pela qual um controlador de tradução de endereços físicos redistribui continuamente a correspondência entre blocos lógicos e blocos físicos, processo denominado nivelamento de desgaste, e mantém páginas fisicamente obsoletas por um intervalo de tempo antes de submetê-las a coleta de lixo. A Figura 2 sintetiza essa sequência de camadas, da instrução de consulta ao estado físico final.

O resultado desta subseção é que a operação descrita coloquialmente como consultar um banco de dados corresponde, em sua execução física completa, a uma sequência de traduções entre representações — sintática, relacional, indexada, tabular, paginada, em memória volátil, em estado elétrico — nenhuma das quais opcional para que a operação lógica se complete.

4.2 Multiplicidade física e controle de concorrência

Considere-se a execução, imediatamente após a consulta anterior, da instrução UPDATE users SET name = ‘Sarah’ WHERE id = 42. O que ocorre fisicamente não constitui uma substituição. O PostgreSQL — e, com mecanismos distintos, a maior parte dos sistemas de gerenciamento de bancos de dados relacionais contemporâneos — não apaga a tupla existente e escreve uma nova em seu lugar: marca a tupla vigente como encerrada, preenchendo seu campo de controle de concorrência t_xmax com o identificador da transação corrente, e insere uma tupla inteiramente nova, com seu próprio campo t_xmin, possivelmente na mesma página, possivelmente em página distinta. Durante um intervalo que depende exclusivamente de quando a rotina de limpeza automática (VACUUM, no PostgreSQL) for executada, duas versões físicas distintas da mesma linha lógica coexistem na tabela — uma vigente, outra obsoleta mas ainda presente, ambas ocupando espaço real em armazenamento. Esse mecanismo, denominado controle de concorrência multiversão, permite que uma transação de leitura observe um retrato consistente dos dados sem bloquear transações de escrita concorrentes: cada transação simplesmente desconsidera as versões cujo intervalo de validade não a inclui. A consistência lógica observada pela aplicação — existe uma linha com id = 42, e ela possui um nome — é obtida ao custo de uma multiplicidade física que a linguagem de consulta estruturada nunca expõe.

Essa multiplicidade não se limita à tabela. Antes de qualquer página ser modificada em seu local definitivo, o sistema de gerenciamento registra a intenção da alteração em um registro de escrita antecipada (write-ahead log, ou WAL): arquivo sequencial, distinto do arquivo da tabela, que descreve a alteração de forma suficiente para reconstruí-la caso o sistema seja interrompido antes que a página modificada alcance o armazenamento persistente. É esse registro — não a página da tabela — que precisa estar fisicamente persistido, por meio de uma chamada de sistema como fsync, para que uma transação seja considerada confirmada com sucesso. A página que contém a tupla efetivamente modificada pode permanecer suja na memória compartilhada por um intervalo posterior à confirmação da transação, sendo escrita em seu local definitivo apenas em um ponto de verificação subsequente. Uma transação confirmada, portanto, não significa que a página final já esteja gravada, mas que existe, em arquivo distinto, informação suficiente para reconstruir a alteração ainda que a página em si se perca — a durabilidade, um dos quatro princípios ACID, é garantida por essa duplicação deliberada, não por uma escrita única e definitiva.

Se o sistema for distribuído, com um servidor primário e uma ou mais réplicas mantidas sincronizadas por algum protocolo de consistência, a multiplicidade descrita se estende adicionalmente. Sob regime de replicação assíncrona, existe uma janela temporal, ainda que breve, em que o servidor primário já processou a alteração e uma réplica específica ainda não a recebeu; nesse intervalo, uma leitura direcionada à réplica devolve o valor anterior, enquanto uma leitura direcionada ao primário devolve o valor atualizado — ambos fisicamente reais no mesmo instante. O valor único e coerente observado pela aplicação é, nesse caso, um efeito produzido pelo protocolo de consistência adotado, não um dado bruto sobre o estado do sistema físico. A Figura 3 sintetiza essa multiplicidade de instanciações físicas simultaneamente possíveis para um mesmo valor lógico.

A conclusão que decorre desta subseção qualifica, sem invalidar, a premissa de que um dado ocupa uma localização física determinada. A qualificação correta não é que o valor examinado seja imaterial, nem que sua localização constitua uma pergunta sem sentido, mas que não existe uma única localização física na qual o valor se encontre: existe um conjunto heterogêneo de instanciações físicas simultâneas — a tupla vigente, uma tupla obsoleta ainda não recolhida, um registro no log de escrita antecipada, possivelmente réplicas parcial e temporariamente desatualizadas —, cada uma delas inteiramente física, cuja convergência para um único valor observável constitui resultado de engenharia de protocolo, não condição natural preexistente.

4.3 Análise comparativa entre implementações

A mesma instrução de consulta pode corresponder à execução de arquiteturas físicas substancialmente distintas, dependendo do sistema de gerenciamento de banco de dados utilizado, como demonstra a comparação sistematizada no Quadro 1.

Quadro 1 – Comparação arquitetural entre sistemas de gerenciamento de bancos de dados relacionais

Fonte: elaborado pela autora com base em documentação oficial dos respectivos sistemas (POSTGRESQL GLOBAL DEVELOPMENT GROUP, [2024]; ORACLE, [2024]; MICROSOFT, [2024]; SQLITE, [2024]).

O PostgreSQL organiza toda tabela como um heap: coleção de páginas sem ordenação física obrigatória, na qual índices — inclusive o índice sobre a chave primária — constituem estruturas inteiramente separadas que apontam de volta para a posição física da tupla no heap. É possível reorganizar fisicamente uma tabela por meio do comando CLUSTER, mas essa ordenação não é mantida automaticamente após sua execução: a primeira inserção subsequente já pode romper o alinhamento entre ordem lógica e ordem física (POSTGRESQL GLOBAL DEVELOPMENT GROUP, [2024]). O InnoDB, motor de armazenamento padrão do MySQL, resolve o mesmo problema de modo distinto: toda tabela é, por definição de sua arquitetura, organizada como índice clusterizado pela chave primária, de modo que os próprios dados da linha residem nas folhas da árvore B+ que indexa essa chave, e não em uma estrutura de heap separada; na ausência de chave primária declarada, o InnoDB cria uma internamente, precisamente porque sua arquitetura não admite a alternativa de um heap não ordenado (ORACLE, [2024]). O SQL Server oferece as duas alternativas como escolha explícita de quem projeta a tabela, que pode permanecer como heap ou ser definida com índice clusterizado — tipicamente, mas não necessariamente, sobre a chave primária —, caso em que as próprias páginas de dados passam a ser fisicamente ordenadas por essa chave (MICROSOFT, [2024]).

Nenhuma dessas três decisões arquiteturais é neutra em termos de desempenho. Uma organização em heap favorece operações de inserção, por não exigir preservação de ordem física, mas penaliza buscas por intervalo, que dependem de um índice secundário apenas para localizar a posição física correspondente. Um índice clusterizado favorece exatamente essas buscas por intervalo — linhas vizinhas na ordenação lógica tendem a permanecer fisicamente próximas, na mesma página ou em páginas adjacentes —, mas encarece operações de inserção que incidem no interior de uma faixa de chaves já densamente povoada, exigindo divisão de páginas para abertura de espaço. Cada arquitetura resolve o mesmo problema lógico — localizar a linha em que id = 42 — mediante um custo físico distinto, sem que nenhum sistema de gerenciamento de banco de dados relacional escape dessa escolha; cada um apenas a torna explícita de forma distinta.

O SQLite introduz uma complicação adicional à comparação, por não possuir, em sentido estrito, um servidor: o motor constitui uma biblioteca vinculada diretamente ao processo da aplicação, de modo que não existem conexão de rede, autenticação, tampouco o protocolo de mensagens binárias descrito na seção 4.1, porque a etapa de comunicação entre cliente e servidor simplesmente não ocorre nessa arquitetura (SQLITE, [2024]). Essa característica não reduz a exigência física de página, estrutura em árvore B e persistência via arquivo de registro de transação, mas colapsa, em um único processo, camadas que em uma arquitetura cliente-servidor permanecem fisicamente separadas por uma fronteira de rede.

Serviços gerenciados de banco de dados em nuvem introduzem, por fim, uma complicação que retorna à pergunta sobre o significado de armazenamento em disco. Em diversas dessas ofertas, o volume que o sistema de gerenciamento trata como dispositivo de bloco local constitui, na realidade, abstração sobre armazenamento distribuído e conectado por rede: o sistema operacional recebe algo que se comporta, sob toda interface relevante, como um disco físico local, mas cuja implementação pode envolver múltiplas máquinas de armazenamento, replicação interna do provedor e um caminho de rede entre o servidor de computação e o dispositivo de armazenamento propriamente dito. Isso implica que uma operação de sincronização física, descrita na seção 4.2 como garantia de durabilidade de uma transação confirmada, pode corresponder, em um serviço gerenciado, a uma confirmação proveniente de um sistema de armazenamento distribuído inteiro, e não de um único disco físico diretamente anexado à máquina que executa o sistema de gerenciamento — a mesma chamada de sistema e o mesmo contrato lógico sustentados por uma cadeia física substancialmente mais longa do que aquela para a qual a chamada foi originalmente projetada.

4.4 Rede, nuvem e responsabilidade compartilhada

Quando o cliente que envia a consulta não reside na mesma máquina que o sistema de gerenciamento de banco de dados, o valor solicitado precisa se deslocar por um trajeto físico concreto: da máquina cliente para uma rede local, desta para o roteador de um provedor de acesso, então para um backbone de longa distância — atualmente, em sua maioria, um cabo de fibra óptica, eventualmente submarino —, até alcançar a rede interna de um data center, atravessar comutadores e roteadores adicionais, e, finalmente, chegar ao servidor específico no qual o sistema de gerenciamento está em execução. Cada segmento dessa cadeia introduz latência mensurável em milissegundos, e cada dispositivo de rede intermediário constitui, ele mesmo, um computador com memória, processador e consumo de energia próprios. Uma consulta remota não constitui, portanto, uma abstração instantânea, mas um objeto com trajetória, distância e tempo de deslocamento físico mensurável, ainda que esse tempo seja, na maioria dos casos, pequeno demais para ser percebido por quem aguarda a resposta.

A expressão nuvem computacional comprime essa complexidade — e mais do que ela — em uma única metáfora associada a leveza e ausência de lugar. Decompô-la em suas configurações concretas é analiticamente produtivo, porque cada configuração corresponde a uma disposição física distinta: um banco de dados pode estar instalado em máquina local; em servidor físico dedicado; em máquina virtual compartilhando hardware com outras cargas de trabalho; em contêiner isolado por mecanismos do sistema operacional; ou consumido como serviço gerenciado, no qual o provedor administra atualizações, cópias de segurança e topologia de replicação, restando ao cliente uma interface lógica de banco de dados. Pode ainda envolver múltiplas zonas de disponibilidade dentro de uma região geográfica, múltiplas regiões para tolerância a desastres, cópias de segurança incrementais armazenadas separadamente do banco ativo, e camadas adicionais de armazenamento de objetos para retenção de longo prazo. Nenhuma dessas configurações constitui isoladamente a nuvem; todas constituem possibilidades simultâneas da nuvem, cada uma com pegada física distinta.

O que a computação em nuvem de fato realiza não é a eliminação dessa infraestrutura física, mas a reorganização de sua administração e, com ela, da responsabilidade sobre cada camada da arquitetura. Provedores de infraestrutura documentam essa reorganização por meio do modelo de responsabilidade compartilhada descrito na seção 3.5: o provedor responde pela segurança da infraestrutura física, da virtualização e das instalações, e o cliente responde pela configuração, pelos dados armazenados e pelo controle de acesso, em uma fronteira que se desloca conforme o serviço contratado corresponda a infraestrutura básica ou a um banco de dados totalmente gerenciado (AMAZON WEB SERVICES, [2024]). Nesse sentido, a nuvem computacional constitui menos um lugar do que um contrato: uma redistribuição específica de responsabilidade sobre cada camada da arquitetura, e de quem remunera qual unidade de consumo.

Essa reorganização possui genealogia que antecede em décadas a expressão cloud computing. Hu (2015) demonstra que a infraestrutura digital contemporânea se desenvolveu sobre redes muito mais antigas — ferroviárias, de saneamento, de radiodifusão televisiva — e que instalações subterrâneas construídas durante a Guerra Fria viriam, décadas depois, a ser reaproveitadas como data centers. O argumento do autor não é meramente histórico: sustenta que a metáfora da nuvem herda, junto de sua leveza estética, uma história de infraestrutura militarizada e geograficamente concentrada que a própria metáfora torna mais fácil ignorar. Star (1999) oferece diagnóstico complementar, de alcance mais geral: toda infraestrutura tende a ser transparente ao uso, sustentando tarefas rotineiras sem exigir reinvenção constante, tornando-se visível apenas no momento em que falha — sob condições normais de operação, a infraestrutura elétrica ou o data center que sustenta uma aplicação não constituem objeto de atenção até que se tornem indisponíveis.

Nenhuma dessas observações implica que a expressão nuvem computacional seja um eufemismo vazio, ou que a afirmação de que um dado está na nuvem seja simplesmente falsa. Implica que essa afirmação descreve corretamente uma condição de administração — a irrelevância, para quem consome o serviço, de saber qual servidor físico específico atende a uma consulta em determinado momento — sem descrever, e sem necessidade de descrever, o fato de que algum servidor físico específico, localizável, com endereço e consumo de energia próprios, efetivamente atende a essa consulta no momento em que ela ocorre.

4.5 Consumo energético e limites termodinâmicos

Todo processo físico irreversível dissipa energia como calor — a comutação de um transistor, a recarga periódica de uma célula de memória dinâmica, a propagação de um sinal por um condutor não constituem eventos gratuitos, no sentido termodinâmico do termo. A seção 3.4 estabeleceu, com base em Landauer (1961, 1991), que esse custo possui um piso teórico mínimo — da ordem de kT ln 2 por bit logicamente apagado — e que esse piso permanece, na prática contemporânea, muitas ordens de grandeza distante do consumo real de hardware. Essa distância é o ponto de partida metodológico desta seção: qualquer tentativa de calcular o custo de carbono de uma consulta a partir do limite de Landauer estaria confundindo um piso físico praticamente irrelevante na prática com um custo real determinado por fatores completamente distintos — padrões de acesso à memória, falhas de cache, escalonamento do sistema operacional, sobrecarga de pilha de rede e, de modo não trivial, eficiência de refrigeração da instalação que abriga o servidor.

O que se mede, na prática de operação de data centers, é a eficiência de uso de energia, descrita na seção 3.5: a razão entre a energia total consumida por uma instalação e a energia que efetivamente alcança o equipamento de computação (THE GREEN GRID, 2012). O calor mensurado por essa métrica corresponde ao mesmo calor produzido, transistor a transistor, pelas operações descritas nas seções 4.1 e 4.2 — agregado, porém, por milhares de servidores em operação contínua, exigindo remoção física da instalação antes que danifique o próprio equipamento que o produz.

Esse calor agregado possui consequências materiais que ultrapassam o consumo de eletricidade isoladamente. A refrigeração de data centers em escala pode envolver consumo significativo de água, seja diretamente em sistemas de refrigeração evaporativa, seja indiretamente na geração da eletricidade consumida; a fabricação do equipamento instalado depende de semicondutores, elementos de terras raras e outros materiais extraídos e processados por meio de cadeias de suprimento globais; e a vida útil relativamente curta desse hardware — substituído não necessariamente por deixar de funcionar, mas por tornar-se ineficiente frente à demanda — produz fluxo constante de resíduo eletrônico. Segundo a Agência Internacional de Energia, o conjunto global de data centers foi responsável por aproximadamente 1,5% do consumo elétrico mundial em 2024 — cerca de 415 terawatt-hora —, com projeção de crescimento para próximo de 945 terawatt-hora até 2030, impulsionado majoritariamente pela expansão de cargas de trabalho de inteligência artificial (INTERNATIONAL ENERGY AGENCY, 2025), como sintetiza a Figura 4.

Gonzalez Monserrate (2022) argumenta, com base em pesquisa etnográfica prolongada em data centers, que essa cadeia de custos ambientais permanece obscurecida pela complexidade das próprias infraestruturas e cadeias de suprimento envolvidas — não por acidente, mas porque cada camada de abstração examinada neste artigo, da linguagem de consulta estruturada ao armazenamento persistente, foi originalmente desenhada para que essa complexidade não precisasse ser considerada por quem depende dela. Hu (2015) chega a constatação correlata por caminho distinto: um único data center pode consumir eletricidade equivalente à de uma cidade de porte médio, permanecendo, para a ampla maioria dos usuários finais, representado por um ícone estilizado de nuvem em uma tela.

Nenhuma das constatações anteriores constitui, isoladamente, uma acusação. Energia é consumida por qualquer forma de computação, assim como por qualquer forma de trabalho físico; a questão relevante não é a existência do custo, mas sua proporcionalidade, sua necessidade, e sua visibilidade para quem toma as decisões de arquitetura que o determinam. A distância entre o limite de Landauer e o consumo real de hardware contemporâneo — da ordem de vinte e duas ordens de grandeza — constitui também uma medida da margem de melhoria de eficiência ainda disponível antes que qualquer limite físico fundamental se torne a restrição efetiva. O calor emitido pela instalação física de um data center constitui, hoje, predominantemente uma medida de ineficiência de engenharia e de escolhas de provisionamento, não de necessidade física fundamental.

A verificação empírica direta das afirmações técnicas apresentadas nesta e nas seções anteriores permanece, nesta versão do artigo, como protocolo proposto e não como resultado incorporado, conforme indicado na seção de materiais e métodos. O Quadro 2 sistematiza os procedimentos técnicos identificados como reproduzíveis para essa verificação, especificando, para cada um, o sistema de gerenciamento de referência e a ressalva metodológica associada.

Quadro 2 – Protocolo de verificação empírica proposto

Fonte: elaborado pela autora.

5. Considerações finais

Este artigo examinou a arquitetura em camadas que separa a sintaxe de uma consulta em linguagem de consulta estruturada de sua execução física completa, com o objetivo de investigar de que modo essa arquitetura reconfigura a relação entre a instanciação física da informação e sua manipulação simbólica. A análise conduzida nas seções 4.1 a 4.5 permite afirmar que essa reconfiguração ocorre em pelo menos três níveis distintos, cuja distinção constitui a principal contribuição conceitual deste trabalho: um nível de necessidade próxima da conceitual, segundo o qual toda operação computacional exige algum suporte físico; um nível de contingência tecnológica, relativo a qual suporte físico específico realiza essa exigência em determinado momento histórico; e um nível de escolha de engenharia, relativo à arquitetura específica — modelo relacional, linguagem de consulta estruturada, virtualização, computação em nuvem — que cada implementação constrói sobre essa contingência. A confusão entre esses três níveis, argumenta este artigo, é responsável por parte relevante da imprecisão observada em discussões acadêmicas e públicas sobre materialidade de dados e sustentabilidade computacional.

A análise técnica comparativa entre PostgreSQL, InnoDB, SQL Server e SQLite, apresentada na seção 4.3, demonstrou que decisões arquiteturais aparentemente equivalentes do ponto de vista lógico correspondem a escolhas de engenharia distintas e não intercambiáveis, cada uma associada a custos e benefícios específicos de desempenho. A análise da multiplicidade física decorrente de mecanismos de controle de concorrência multiversão, registro de escrita antecipada e replicação distribuída, apresentada na seção 4.2, qualificou a premissa de que um dado ocupa localização física única, substituindo-a por descrição mais precisa e, argumenta-se, mais produtiva: a de um conjunto heterogêneo de instanciações físicas simultâneas cuja convergência para um valor lógico único constitui resultado de protocolo de engenharia, não condição natural preexistente. Por fim, a análise da distância entre o limite termodinâmico teórico estabelecido por Landauer (1961, 1991) e o consumo energético real de infraestrutura computacional contemporânea, apresentada na seção 4.5, estabeleceu disciplina metodológica que este artigo considera indispensável a qualquer discussão rigorosa de sustentabilidade computacional: a de não atribuir a limites físicos fundamentais custos ambientais que decorrem, na prática observável, de escolhas de engenharia e de provisionamento contingentes.

Este artigo apresenta limitações que devem ser reconhecidas explicitamente. Em primeiro lugar, a verificação empírica direta dos procedimentos técnicos sistematizados no Quadro 2 não foi incorporada a esta versão do trabalho, permanecendo como protocolo de validação proposto; sua incorporação constitui extensão natural e necessária desta pesquisa. Em segundo lugar, a análise comparativa entre implementações concentrou-se em quatro sistemas de gerenciamento de banco de dados relacionais amplamente utilizados, sem estender-se a sistemas relacionais distribuídos nativos de nuvem, cuja arquitetura interna provavelmente introduz multiplicidades físicas adicionais não examinadas neste trabalho. Em terceiro lugar, a discussão de custo ambiental apresentada na seção 4.5 não incorporou dados quantitativos originais de consumo energético ou de emissões, apoiando-se exclusivamente em literatura e documentação institucional já publicadas, por decisão metodológica deliberada de não estimar valores sem base empírica direta.

Como agenda de pesquisa futura, sugere-se: a execução do protocolo de verificação empírica sistematizado no Quadro 2, com publicação de seus resultados como extensão direta deste artigo; a extensão da análise comparativa a sistemas de bancos de dados distribuídos nativos de nuvem; e a investigação, em trabalho dedicado, da possibilidade de mensuração empírica direta do consumo energético associado a operações específicas de manipulação de dados, em condições controladas e com explicitação completa da metodologia de medição, de modo a testar empiricamente a disciplina metodológica proposta na seção 4.5 deste artigo.

Referências

AMAZON WEB SERVICES. AWS shared responsibility model. [S. l.]: Amazon Web Services, [2024]. Disponível em: https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/shared-responsibility-model.html. Acesso em: 20 ago. 2026.

ANSI/X3/SPARC STUDY GROUP ON DATA BASE MANAGEMENT SYSTEMS. Interim report. FDT — ACM SIGMOD Bulletin, New York, v. 7, n. 2, 1975.

BENNETT, C. H.; LANDAUER, R. The fundamental physical limits of computation. Scientific American, New York, v. 253, p. 48-57, jul. 1985.

BLANCHETTE, J.-F. A material history of bits. Journal of the American Society for Information Science and Technology, Hoboken, v. 62, n. 6, p. 1042-1057, jun. 2011.

CODD, E. F. A relational model of data for large shared data banks. Communications of the ACM, New York, v. 13, n. 6, p. 377-387, jun. 1970.

GONZALEZ MONSERRATE, S. The cloud is material: on the environmental impacts of computation and data storage. MIT Case Studies in Social and Ethical Responsibilities of Computing, Cambridge, Winter 2022. Disponível em: https://doi.org/10.21428/2c646de5.031d4553. Acesso em: 20 ago. 2026.

HU, T.-H. A prehistory of the cloud. Cambridge: MIT Press, 2015.

INTERNATIONAL ENERGY AGENCY. Energy and AI. Paris: IEA, 2025. Disponível em: https://www.iea.org/reports/energy-and-ai. Acesso em: 20 ago. 2026.

KIRSCHENBAUM, M. G. Mechanisms: new media and the forensic imagination. Cambridge: MIT Press, 2008.

LANDAUER, R. Irreversibility and heat generation in the computing process. IBM Journal of Research and Development, New York, v. 5, p. 183-191, 1961.

LANDAUER, R. Information is physical. Physics Today, College Park, v. 44, n. 5, p. 23-29, maio 1991.

MICROSOFT. sys.dm_db_page_info (Transact-SQL). [S. l.]: Microsoft, [2024]. Disponível em: https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-db-page-info-transact-sql. Acesso em: 20 ago. 2026.

ORACLE. MySQL 8.4 reference manual: the InnoDB storage engine. [S. l.]: Oracle, [2024]. Disponível em: https://dev.mysql.com/doc/refman/8.4/en/innodb-storage-engine.html. Acesso em: 20 ago. 2026.

POSTGRESQL GLOBAL DEVELOPMENT GROUP. PostgreSQL: documentation: pageinspect. [S. l.]: PostgreSQL Global Development Group, [2024]. Disponível em: https://www.postgresql.org/docs/current/pageinspect.html. Acesso em: 20 ago. 2026.

SQLITE. Architecture of SQLite. [S. l.]: SQLite, [2024]. Disponível em: https://sqlite.org/arch.html. Acesso em: 20 ago. 2026.

STAR, S. L. The ethnography of infrastructure. American Behavioral Scientist, Thousand Oaks, v. 43, n. 3, p. 377-391, 1999.

THE GREEN GRID. PUE: a comprehensive examination of the metric. [S. l.]: The Green Grid, 2012.