Airtable é uma plataforma de aplicativos nativa de IA na qual basta descrever a necessidade em linguagem corrente para obter tabelas, interfaces, automações e agentes de IA rodando sobre os dados reais da equipe, com governança de administrador e conformidade corporativa.
Já usou esta ferramenta? Avalie-a
Já usou esta ferramenta? Avalie-a
O Airtable é uma plataforma de banco de dados relacional criada para que profissionais de negócio consigam estruturar informação complexa, montar aplicações internas em cima dela e automatizar o trabalho ao redor — tudo isso sem depender de um time de engenharia. A própria empresa se define como "o sistema de registro para empresas que estão construindo o que vem a seguir". E a chamada da página inicial resume a aposta em uma frase: "A IA transformou o trabalho individual. O Airtable transforma o trabalho em equipe". Vale prestar atenção nessa distinção, porque ela não é retórica. A maior parte das ferramentas de IA hoje otimiza o desempenho de uma pessoa sozinha diante da tela. O Airtable mira o espaço entre as pessoas — as passagens de bastão entre áreas, os dados espalhados em planilhas que ninguém consegue reconciliar, os processos que existem só na cabeça de quem os executa.
Por baixo de toda a camada de inteligência artificial continua existindo um banco de dados relacional operável por gente comum, e entender isso é pré-requisito para avaliar o produto direito. A unidade de trabalho é a base, um contêiner que reúne várias tabelas. Cada tabela tem campos tipados — texto, número, data, seleção única, seleção múltipla, anexo, caixa de seleção, fórmula e assim por diante — no lugar de células genéricas em que qualquer coisa cabe em qualquer lugar. E o mais importante: registros de tabelas diferentes se vinculam entre si. Um registro da tabela "Pedidos" aponta para um registro específico de "Clientes", que por sua vez se conecta a vários registros de "Contatos". É esse vínculo que separa o Airtable de uma planilha, e é ele que permite que um mesmo dado exista uma única vez e seja consultado de vários lugares sem duplicação nem desencontro de versões.
Em 24 de junho de 2025, a carta pública do CEO chamou a reconstrução da plataforma em torno da IA de "momento de refundação" da companhia. A distinção feita naquele texto interessa a qualquer pessoa comparando ferramentas: não se tratava de acoplar recursos de IA a uma plataforma pronta, mas de refazer o produto partindo do princípio de que a IA é a linha principal, e não uma camada adicional. Na prática, isso quer dizer que os agentes e o construtor conversacional não moram num menu secundário nem numa aba de "extras" — estão dentro do modelo de dados, dentro de cada registro e dentro do motor de automações. Quem for avaliar o Airtable em 2026 deveria julgá-lo por essa arquitetura, não pela imagem de "planilha bonita" que a ferramenta carregava anos atrás.
O efeito prático dessa natureza dupla — rigor relacional embaixo, interface acessível e conversacional em cima — é que o Airtable ocupa uma faixa pouco povoada do mercado. Abaixo dele estão as planilhas: baratas, familiares e incapazes de sustentar estrutura relacional ou permissões finas. Acima estão os bancos de dados de verdade e as plataformas de ferramentas internas: potentes, mas dependentes de perfis técnicos. O Airtable fala com times que já bateram no teto da planilha e não querem — ou não conseguem — abrir um chamado para engenharia toda vez que precisam de uma visão nova, de um fluxo de aprovação ou de um relatório diferente.
O Omni é a porta de entrada do produto na versão atual. Você descreve em linguagem comum o que precisa — "um sistema para acompanhar candidaturas com etapas de entrevista, notas dos entrevistadores e uma tela para o gestor da vaga" — e o Omni gera a aplicação inteira: tabelas com campos tipados, vínculos entre elas, interfaces e automações. O ponto que separa isso de um gerador de modelos prontos é que o resultado continua totalmente editável pelas ferramentas visuais de sempre. Não sai dali um artefato opaco que só a IA sabe mexer; sai uma base normal do Airtable, com esquema visível, que qualquer pessoa reorganiza campo a campo. Além disso, construir aplicações e agentes com o Omni é gratuito e não consome créditos, o que elimina o freio psicológico de testar três ou quatro versões de um modelo de dados antes de decidir qual fica.
Os agentes do Airtable analisam dados, geram conteúdo e fazem pesquisa de forma automática e em escala. A forma mais granular são os Field Agents, que funcionam dentro de cada registro: um campo cujo valor é produzido por um agente a partir do restante daquele registro. Ao lado deles existem outros formatos. A análise de documentos varre contratos e faturas atrás de sinais de alerta. A busca na web enriquece leads, analisa concorrentes e resume notícias, trazendo contexto externo para registros que até então continham apenas o que alguém digitou. Há também tradução e geração de imagens. Qualquer um desses agentes pode ser configurado para rodar automaticamente sempre que dados forem adicionados ou atualizados, transformando o enriquecimento numa propriedade do sistema em vez de uma tarefa que alguém precisa lembrar de fazer.
O motor de automações trabalha no modelo gatilho e ação, configurável sem escrever código: quando um registro entra num determinado estado, quando um formulário chega, quando uma condição de data se cumpre, dispara-se uma sequência de ações. Para os casos em que a lógica declarativa não dá conta, é possível inserir JavaScript dentro do próprio fluxo, o que abre espaço para transformações de dados, chamadas condicionais e cálculos que nenhuma tela de configuração cobriria de forma razoável. Existem ainda conexões nativas com Slack, Google Workspace e ferramentas semelhantes, de modo que o fluxo não termina na fronteira do Airtable: ele empurra notificações, cria eventos e grava documentos onde o time já trabalha.
O Interface Designer permite montar e compartilhar interfaces sob medida sem código, definindo quem enxerga o quê. É a peça que transforma um banco de dados em algo apresentável para pessoas que não deveriam encostar na tabela bruta: um painel de indicadores para a diretoria, uma tela de revisão para quem só precisa aprovar pendências, um formulário de entrada para um time externo. O Airtable observa que algumas funcionalidades, em especial as ligadas a permissões, são exclusivas de determinados níveis de preço — detalhe que convém conferir antes de desenhar um modelo de acesso que dependa delas.
No plano administrativo, os administradores gerenciam o uso de IA e a habilitam no nível do espaço de trabalho, controlam a quais dados os agentes têm acesso, e toda a atividade fica governada e auditável. Os níveis Enterprise acrescentam painel de administração, registros de auditoria, gerenciamento corporativo de chaves e prevenção contra perda de dados. É essa camada que viabiliza a adoção em organizações onde o simples fato de um modelo ler uma tabela de clientes exige justificativa formal junto à área de segurança.
O HyperDB sincroniza e escala conjuntos de dados mesmo com mais de 100 milhões de registros. É a resposta do Airtable à objeção histórica de que a plataforma não serviria para volume sério: ele deixa o dado massivo acessível a partir do ambiente de trabalho sem tentar espremê-lo dentro dos limites de registros de uma base comum. Guarde, porém, um ponto: trata-se de capacidade de nível corporativo, e não de um remédio disponível para quem esbarra no teto de registros num plano inferior.
A última funcionalidade central é a mais antiga e a que sustenta todas as outras: a capacidade de um usuário de negócio operar um modelo relacional de verdade. Campos tipados, registros vinculados entre tabelas, buscas que trazem valores do registro vinculado e agregações que resumem coleções de registros filhos. Sem essa base, a IA geraria conteúdo sobre dados desestruturados e o resultado seria tão pouco confiável quanto a origem.
Um time de marketing que toca o calendário numa planilha compartilhada vive um roteiro conhecido: uma aba por trimestre, colunas que alguém renomeou sem avisar, status digitados à mão que aparecem como "em revisão", "revisão" e "Em Revisão" na mesma coluna, e nenhum vínculo real entre o artigo e quem o escreve além de um nome batido no teclado. Refeito no Airtable, a tabela de conteúdos se liga a uma tabela de autores e a outra de campanhas; o status vira campo de seleção única com valores fechados; as datas de publicação alimentam uma visão de calendário. Em cima disso entra uma automação que avisa o editor no Slack quando um artigo muda para "pronto para revisão", e um agente que gera um primeiro rascunho de meta descrição e de post social a partir do corpo do texto, rodando sozinho assim que o campo é preenchido. O ganho não é estético: some a reconciliação manual entre abas e some a pergunta semanal de "em que pé está isso?".
Antes: um quadro de tarefas para as etapas, um documento compartilhado com as notas de entrevista, uma thread de e-mail para combinar agendas e uma pasta de currículos que ninguém sabe se está atualizada. Depois: uma base com tabelas de candidatos, vagas, entrevistas e entrevistadores, todas vinculadas. Cada entrevista vira um registro próprio apontando para um candidato e para um entrevistador, então a ficha do candidato agrega automaticamente todas as entrevistas dele. Os currículos entram como anexo e um agente de análise de documentos extrai tempo de experiência, tecnologias citadas e localização, gravando tudo em campos consultáveis. O Interface Designer entrega ao gestor da vaga uma tela apenas com as vagas e os candidatos dele, sem acesso aos dados de remuneração que o time de pessoas enxerga. O resultado mensurável é que a informação para de existir em três lugares com três versões diferentes da verdade.
Um time de compras que cuida de centenas de contratos costuma ter o PDF num repositório, as datas de renovação num lembrete de calendário e as condições comerciais na memória de alguém. No Airtable, cada contrato é um registro com o documento anexado, vinculado ao fornecedor e ao centro de custo. O agente de análise de documentos passa por cada contrato no momento do upload procurando sinais de alerta e escreve o que achou num campo de observações, de modo que a revisão humana começa com uma lista de pontos a olhar em vez de um PDF de quarenta páginas. Uma automação avisa noventa dias antes de cada data de renovação, com o disparo vindo do próprio campo de data e não da memória de ninguém. A revisão humana continua obrigatória — o agente sinaliza, não decide — mas o custo da primeira passada cai muito.
O time comercial sobe uma lista de contas-alvo com pouco mais que nome e domínio. Um agente de busca na web roda automaticamente sobre cada registro novo e acrescenta setor, porte aproximado segundo fontes públicas, notícias recentes e um resumo do posicionamento. Outro agente gera um primeiro ângulo de abordagem ajustado ao que foi encontrado. O vendedor deixa de gastar a primeira meia hora de cada conta lendo o site do potencial cliente e já começa com material de contexto na mão. Em paralelo, uma tabela de concorrentes com o mesmo mecanismo mantém atualizado um resumo de lançamentos e mudanças de preço que antes dependia de alguém ter tempo de olhar. É justamente aqui que o consumo variável de créditos aparece com mais força: cada registro enriquecido custa, e uma carga em massa de milhares de contas precisa ser planejada com a cota mensal em mente.
Um time que administra catálogo precisa que uma mesma ficha alimente o site, o material de vendas e o sistema de estoque. No Airtable a ficha existe uma única vez, vinculada a categorias, fornecedores e variantes. As imagens são anexos do próprio registro, e um agente de geração de imagens pode produzir variações visuais para material promocional a partir da ficha existente. O Interface Designer entrega ao time de loja uma visão somente leitura com o que ele precisa e ao time de produto uma visão de edição completa. A automação empurra mudanças de preço para um canal no Slack, evitando que alguém descubra reajuste pelo chamado de um cliente.
É o caso clássico do trabalho que empaca nas passagens de bastão: um projeto que vai de design para desenvolvimento, de desenvolvimento para qualidade e daí para lançamento, com cada área mantendo o próprio controle paralelo. Centralizado numa base com tabelas de projetos, marcos, entregáveis e times, cada passagem vira uma mudança de estado que dispara notificação para o próximo responsável. As interfaces por papel resolvem a reclamação recorrente de que "a ferramenta do outro time tem ruído demais": cada um enxerga a própria tela, sobre os mesmos dados. Um agente pode montar o resumo semanal do projeto a partir das mudanças registradas, substituindo o relatório que alguém escrevia à mão na sexta-feira.
O erro mais caro no começo é abrir uma base e sair criando colunas como se fosse planilha. Vale gastar meia hora no papel listando as entidades do processo — clientes, pedidos, produtos, pessoas — e as relações entre elas. Cada entidade vira uma tabela; cada relação, um campo de vínculo. Se o mesmo dado aparece repetido em dois lugares (o nome do fornecedor digitado em cada linha de pedido, por exemplo), quase sempre é sinal de que falta uma tabela.
Com o modelo mental claro, descrever o sistema para o Omni acelera muito a construção inicial: ele gera tabelas, campos, interfaces e automações de uma vez. O que vem depois é igualmente importante — revisar o esquema gerado campo a campo e ajustar. Os tipos escolhidos por padrão nem sempre são os corretos, e trocar um texto livre por uma seleção única com valores fechados economiza meses de dado sujo. Como construir com o Omni não consome créditos, dá para iterar a descrição várias vezes antes de fixar uma versão.
Um modelo que funciona com vinte linhas inventadas pode quebrar com duas mil linhas de verdade. Importar um volume representativo cedo revela problemas de tipagem, valores que não cabem nas opções fechadas e duplicatas que obrigam a repensar a chave do registro. Serve também para calibrar o limite de registros por base do plano contratado antes de já ter construído tudo em cima.
As visões dentro da tabela — filtradas, agrupadas, ordenadas — resolvem a maioria das necessidades de consulta e custam quase nada de esforço. Só quando a visão não basta, porque o usuário final não deve ver a tabela bruta ou precisa de outra disposição, é hora de recorrer ao Interface Designer. Construir interface cedo demais gera manutenção que depois ninguém quer assumir.
As automações que mais rendem são as que cobrem o momento em que o trabalho troca de mãos: avisar o próximo responsável, mover o registro de estado, criar os registros filhos de que a etapa seguinte precisa. Automatizar uma tarefa que uma pessoa já faz com consistência agrega pouco; automatizar o ponto onde o trabalho fica parado esperando alguém perceber agrega muito.
Comece por um Field Agent num campo específico — um resumo, uma classificação, uma extração — e observe a qualidade do resultado por um período com dados reais antes de ligar a execução automática em cada registro novo. Essa ordem protege duas coisas: a qualidade do dado e o consumo de créditos, que em execução automática sobre tabelas com muita escrita pode crescer mais rápido do que se imagina.
Antes de abrir a base para colaboradores, defina no nível do espaço de trabalho qual IA está habilitada e a quais dados os agentes podem chegar. Decida também quem realmente precisa de permissão de edição: como a cobrança é por usuário, cada convite com direito de edição tem custo direto. Revisar a atividade auditável periodicamente fecha o ciclo.
As conexões nativas com Slack e Google Workspace cobrem a maior parte das necessidades de notificação e documentos. Para o restante, a API web segue semântica REST, codifica os objetos em JSON e usa códigos de status HTTP padrão, com cotas de chamadas por plano que precisam ser dimensionadas: mil chamadas mensais por espaço de trabalho no plano gratuito se esgotam com uma integração de sincronização bem modesta.
Normalize antes de crescer. Sempre que um valor de texto se repetir em muitos registros, transforme-o numa tabela vinculada. Fazer isso com duzentos registros leva minutos; com vinte mil, vira projeto. É a decisão que mais determina se uma base sobrevive dois anos ou se vai precisar ser refeita do zero.
Use seleção única no lugar de texto livre para qualquer status. Campo de status digitado à mão é a causa número um de relatório que não fecha. Um conjunto fechado de opções leva um minuto para configurar e elimina uma classe inteira de problema de qualidade de dado.
Trate os créditos de IA como orçamento compartilhado, porque é o que eles são. A cota mensal por usuário pago é agrupada no nível do espaço de trabalho nos planos Free e Team, e no nível da organização nos planos Business e Enterprise Scale. Ou seja: uma automação mal calibrada de um time pode consumir a cota de todo mundo. Antes de ligar um agente em cada escrita de uma tabela de alto volume, estime quantas execuções isso representa por mês e combine com os outros times qual fatia do orçamento aquilo ocupa.
Teste os agentes em modo manual antes de automatizá-los. Rodar o agente sobre uma amostra de registros e conferir o resultado na mão revela problemas de instrução que não aparecem em dois exemplos. Só quando a qualidade estiver estável vale ligar a execução a cada adição ou atualização de dados.
Desenhe as interfaces para o usuário mais limitado, não para o administrador. A tentação é expor tudo por precaução. O resultado é que o usuário final não acha o que precisa e volta a pedir as coisas por e-mail. Uma interface com três elementos que resolve noventa por cento das consultas vale mais que um painel exaustivo que ninguém usa.
Audite as permissões de edição a cada trimestre. A cobrança por usuário transforma cada colaborador com edição em custo recorrente. É comum que o direito de edição seja concedido de forma casual para destravar um pedido pontual e que ninguém o remova depois. Uma revisão periódica de quem tem edição e quem de fato precisa dela evita fatura surpresa na renovação.
Documente o esquema dentro da própria base. Uma tabela de documentação descrevendo cada tabela, o propósito dos campos calculados e as automações ativas custa pouco e evita que a base fique ilegível quando a pessoa que a construiu sai. Isso pesa ainda mais quando parte do esquema veio do Omni: quem herda não participou da conversa que deu origem àquilo.
Fique de olho no limite de registros por base desde o primeiro dia. O limite vale por base, não por espaço de trabalho, e chega antes do que a maioria espera em dados transacionais. Se uma tabela cresce a cada operação de negócio — logs, eventos, itens de pedido — planeje desde o início onde o histórico vai morar e o que será arquivado fora.
Times de operações que já estouraram a planilha. É o perfil mais evidente. Tocam processos com várias entidades relacionadas, já têm um arquivo compartilhado que cresceu além do sustentável e precisam de estrutura sem abrir um projeto de engenharia. O Airtable entrega exatamente o degrau seguinte.
Times de marketing e conteúdo. Calendário editorial, gestão de campanhas, controle de ativos e catálogo de peças criativas encaixam naturalmente no modelo relacional, e os agentes de geração de conteúdo e tradução cobrem tarefas que consumiam horas de trabalho repetitivo.
Times de gente e recrutamento. Funis de candidatos com múltiplas etapas, entrevistadores e anotações são caso relacional de manual, e as necessidades de permissão — quem enxerga remuneração, quem enxerga só o status — são exatamente o que o Interface Designer resolve.
Times comerciais e de inteligência de mercado. O enriquecimento automático de contas via busca na web e o acompanhamento estruturado de concorrentes agregam valor imediato sobre listas que hoje são estáticas.
Times de produto e de projetos. O acompanhamento de marcos, entregáveis e dependências entre áreas aproveita tanto a estrutura relacional quanto as automações de passagem de bastão, que é justamente onde esses processos costumam empacar.
Times de compras, jurídico e administrativo. A análise de documentos sobre contratos e faturas, com alertas de renovação disparados por campos de data, substitui um controle que hoje depende de lembretes pessoais.
Organizações com exigências formais de conformidade. As certificações SOC 2 Type 2, ISO/IEC 27001:2022, ISO/IEC 27701:2019, HIPAA e TX-RAMP Level 2, somadas à opção de armazenar dados na União Europeia e, no nível corporativo, com chaves de propriedade do próprio cliente, viabilizam a adoção em setores onde isso é requisito de entrada.
Para quem não é. Se o time precisa de uma planilha com fórmulas complicadas e sem relação entre entidades, o modelo relacional é custo sem benefício. Se a aplicação interna precisa se apoiar num banco de dados que já existe e o time tem perfil técnico, uma plataforma de ferramentas internas encaixa melhor. E se o número de colaboradores com permissão de edição for muito alto em relação ao uso efetivo, o modelo de preço por usuário joga contra.
O navegador é o ambiente principal e não exige instalação alguma. Toda a construção de bases, o desenho de interfaces, a configuração de automações e a interação com o Omni e com os agentes acontecem na web, o que elimina o problema clássico de versões diferentes entre membros do time e facilita a adoção em organizações com parque de máquinas gerenciado.
O Airtable oferece ainda aplicativos para desktop e para celular. Dito isso, as avaliações específicas nas lojas de aplicativos, os tamanhos de download e as versões mínimas de sistema operacional não puderam ser confirmados de forma independente (a verificar), então convém checar esses detalhes direto nas lojas antes de assumir compatibilidade com um parque específico de dispositivos. A recomendação prática vale em qualquer cenário: o app de celular atende bem consulta, captura rápida de dados e aprovações, enquanto a construção do esquema e das interfaces fica muito mais confortável em tela grande.
No plano da integração programática, a API web segue semântica REST, codifica os objetos em JSON e utiliza códigos de status HTTP padrão, o que a torna imediatamente familiar para qualquer pessoa desenvolvedora. As cotas de chamadas variam por plano: mil chamadas por espaço de trabalho por mês no gratuito, cem mil no Team e sem limite no Business. Essa diferença pesa no desenho de sincronizações — um processo que verifica mudanças a cada poucos minutos queima cota num ritmo que inviabiliza o plano gratuito para integração de verdade.
As conexões nativas com Slack, Google Workspace e ferramentas semelhantes cobrem a faixa de integração que dispensa código, e dão conta da maior parte dos fluxos de notificação, agenda e documentos.
Free. Mil registros por base, um gigabyte de anexos por base, duas semanas de histórico de revisões e snapshots, e mil chamadas de API por espaço de trabalho por mês. É um plano adequado para avaliar a ferramenta, montar uma prova de conceito ou sustentar um processo pequeno e estável. O limite de mil registros por base costuma ser o primeiro a inviabilizar o uso produtivo.
Team. Vinte dólares por usuário por mês na cobrança anual. Sobe para cinquenta mil registros por base, vinte gigabytes de anexos, um ano de histórico de revisões e cem mil chamadas de API por espaço de trabalho por mês. É o degrau natural para um time que já opera um processo real na plataforma.
Business. Quarenta e cinco dólares por usuário por mês na cobrança anual. Cento e vinte e cinco mil registros por base, cem gigabytes de anexos, um ano de histórico de revisões e chamadas de API ilimitadas. O salto de preço em relação ao Team se justifica quando as capacidades de nível superior fazem falta ou quando o volume de integração transforma a cota de chamadas em gargalo.
Enterprise Scale. Preço sob consulta, conforme as necessidades e a escala da organização. É o nível que incorpora painel de administração, registros de auditoria, gerenciamento corporativo de chaves e prevenção contra perda de dados, além do HyperDB para conjuntos que passam de cem milhões de registros e da possibilidade de armazenar dados em repouso com chaves de propriedade do cliente.
Créditos de IA. Cada plano inclui uma cota mensal por usuário pago. O detalhe que mais afeta o planejamento é o agrupamento: os créditos são compartilhados no nível do espaço de trabalho nos planos Free e Team, e no nível da organização nos planos Business e Enterprise Scale. Não há reserva individual, então o consumo é recurso comum. Cada ação consome um número variável de créditos conforme os dados de entrada, o modelo selecionado e os dados de saída, o que faz da estimativa prévia algo que exige teste real e não cálculo teórico. Para clientes de autoatendimento existem pacotes adicionais: dez mil créditos por vinte dólares mensais, cem mil por duzentos dólares mensais e quatrocentos mil por oitocentos dólares mensais. Guarde um ponto favorável: construir aplicações e agentes com o Omni é gratuito e não consome créditos, então a fase de desenho não disputa orçamento com a de operação.
Como ler esses preços na hora de orçar. O custo total depende de duas variáveis independentes: o número de pessoas com acesso de edição, que define a conta de licenças, e o volume de execuções de IA, que define o consumo de créditos e os eventuais pacotes extras. Um time de dez pessoas com uso intenso de agentes pode acabar pagando mais em créditos do que em licenças; um time de sessenta pessoas com uso leve de IA terá o problema oposto. Modelar as duas dimensões separadamente evita surpresa.
Notion. É mais forte como espaço de documentação e conhecimento. Seus bancos de dados existem, mas estão a serviço das páginas e dos documentos; quando o centro de gravidade do trabalho é escrever, colaborar em texto e organizar conhecimento, o Notion encaixa melhor. Quando o centro de gravidade é um modelo de dados com relações estritas e permissão por papel, o Airtable sustenta com mais solidez.
Smartsheet. Fica mais perto da gestão tradicional de projetos e portfólio. Seu modelo mental é o cronograma, a dependência entre tarefas e o relatório de portfólio, com origem claramente ligada à planilha de gestão de projetos. É escolha mais natural para escritórios de projetos formais do que para construir aplicações internas sobre dados de negócio.
Monday.com. É primeiro uma ferramenta de gestão do trabalho e só depois um banco de dados. Brilha em visualização de tarefas, acompanhamento de carga do time e fluxos colaborativos; sua camada de dados é menos relacional. Se o objetivo é coordenar pessoas mais do que modelar informação, a comparação pende para o lado dele.
Google Sheets com Apps Script. É a opção mais barata e a mais universalmente conhecida, e com Apps Script automatiza bastante coisa. O que não entrega é estrutura relacional de verdade nem compartilhamento com permissão fina: não há tipagem estrita de campos, não há vínculo entre registros com integridade, e controlar quem vê qual parte dos dados obriga a duplicar arquivos. Funciona até o processo crescer.
Baserow e NocoDB. São alternativas de código aberto e auto-hospedáveis. A vantagem principal é o controle total sobre onde os dados residem e sobre o custo, o que as torna atraentes quando residência de dados ou contenção de gastos pesam mais do que a camada de IA. Em troca, assumir a operação da infraestrutura e abrir mão dos agentes integrados faz parte do acordo.
Retool. É voltado a construir ferramentas internas sobre bancos de dados que já existem, e exige escrever código. É a escolha certa quando o dado já mora num sistema próprio bem modelado e o que falta é a interface para operá-lo, com time técnico disponível. Não disputa o terreno de um usuário de negócio montar o modelo de dados sozinho.
Cobrança por assento. Cada colaborador que precisa de acesso de edição soma custo, e esse custo escala com o número de pessoas, não com o uso. É a limitação que mais aparece em discussões da comunidade, quase sempre com o mesmo enredo: alguém concedeu direito de edição de forma casual para destravar um pedido, o padrão se repetiu por meses, e a fatura de renovação chegou com um número que ninguém tinha previsto. Para a decisão de compra a implicação é direta: é preciso modelar o número de editores num horizonte de doze e vinte e quatro meses, não o número de hoje, e estabelecer desde o início um critério explícito de quem ganha edição e quem fica em consulta.
Limites de registros por base. O limite vale por base, não por espaço de trabalho nem por organização, e chega antes do que a intuição sugere. Mil registros no Free e cinquenta mil no Team parecem folgados até que sejam aplicados a dados transacionais: itens de pedido, eventos de processo, entradas de log de atividade. Cada operação de negócio gera registro, e tabela de histórico cresce de forma monotônica. O HyperDB, que escala para além de cem milhões de registros, é capacidade de nível corporativo — não é remendo disponível para quem bate no teto num plano inferior. Antes de comprometer um processo de alto volume, calcule o crescimento anual de registros e verifique contra qual limite você vai esbarrar e quando.
Consumo variável de créditos de IA. O número de créditos de cada ação depende dos dados de entrada, do modelo selecionado e dos dados de saída, o que torna a estimativa prévia bastante difícil. Some a isso o fato de que a cota é agrupada — por espaço de trabalho no Free e no Team, por organização no Business e no Enterprise Scale — em vez de reservada por pessoa: a automação de um time pode esgotar a cota compartilhada e deixar os demais sem capacidade. Para quem compra, isso significa que o orçamento de IA não é linha fixa e sim recurso que exige governança interna, com acordo explícito sobre quem pode ligar execuções automáticas de alto volume.
Curva de aprendizado real. O raciocínio relacional — vínculos, buscas e agregações — é a barreira principal para quem vem de planilha. Não é questão de interface, e sim de modelo mental: entender por que o nome do fornecedor não deve ser digitado em cada linha exige uma virada conceitual que nem todo mundo faz sozinho. Na prática, isso implica reservar orçamento de treinamento e aceitar que as primeiras bases construídas pelo time provavelmente vão precisar ser refeitas. Ignorar esse ponto é a causa habitual de adoções que param no meio do caminho.
Recursos limitados por nível de plano. Algumas capacidades estão reservadas a determinados níveis de preço, em especial as ligadas a permissões. Isso importa porque permissão costuma ser o requisito que aparece tarde: o sistema é construído, chega a hora de compartilhar com uma área externa e só aí se descobre que o controle de acesso necessário está num plano superior. Conferir o detalhe de permissões por nível antes de desenhar o modelo de acesso evita retrabalho ou um upgrade fora do orçamento.
Mudança de controle acionário pendente. Em 4 de agosto de 2026 a Bending Spoons anunciou um acordo definitivo para adquirir o Airtable por um valor de empresa de 1,285 bilhão de dólares. A operação não foi concluída: está sujeita a aprovações regulatórias e às condições de fechamento habituais, com expectativa de conclusão ainda neste ano, e até lá as duas companhias seguem operando de forma independente. O produto, a marca e o domínio permanecem os mesmos. Para o uso do dia a dia isso não tem efeito imediato, mas para decisões de contratação plurianual vale considerar: depois do fechamento, a autoridade sobre preços e sobre o roteiro do produto pode mudar de mãos. Quem estiver assinando compromisso de vários anos faz bem em negociar condições de preço e em conhecer as vias de exportação de dados disponíveis.
Revisão humana obrigatória sobre o que é gerado. As aplicações geradas pelo Omni continuam exigindo revisão humana, e isso é recomendação operacional, não formalidade. O esquema gerado tende a ser razoável na forma geral, mas os erros aparecem no detalhe: um campo tipado como texto livre onde deveria ser seleção fechada, uma relação montada na cardinalidade errada, uma automação cuja condição de disparo é ampla demais. Esses problemas são triviais de corrigir no primeiro dia e caríssimos depois que existem dezenas de milhares de registros apoiados num modelo defeituoso. A disciplina correta é tratar a saída do Omni como um primeiro rascunho competente, não como entrega final.
Privacidade e conformidade: o que está definido. A declaração oficial é que os provedores de modelos nunca retêm os dados do cliente e que esses dados nunca são usados para treinar modelos. Clientes corporativos decidem quais modelos ficam habilitados, entre provedores que incluem OpenAI, Anthropic, Meta e outros. As certificações são SOC 2 Type 2, ISO/IEC 27001:2022, ISO/IEC 27701:2019, HIPAA e TX-RAMP Level 2. Existe a opção de armazenar os dados na União Europeia, e clientes corporativos podem armazenar dados em repouso com chaves de sua propriedade. Residentes do Espaço Econômico Europeu, do Reino Unido e da Suíça têm direitos de acesso, portabilidade, retificação, exclusão, restrição, retirada de consentimento e oposição; residentes dos estados norte-americanos aplicáveis têm direitos de acesso, exclusão, correção e recurso. A política de privacidade foi atualizada pela última vez em 15 de julho de 2026.
É um banco de dados relacional que apresenta uma interface familiar para quem vem de planilha, mas o modelo por baixo é diferente — e essa diferença é a razão de existir do produto. Na planilha cada célula é independente e aceita qualquer coisa; no Airtable os campos são tipados e os registros de tabelas distintas se vinculam entre si, de modo que um dado existe uma única vez e é consultado de onde for preciso. Isso viabiliza integridade referencial, agregações confiáveis e permissões por papel que planilha nenhuma sustenta. A contrapartida é que exige pensar em entidades e relações antes de começar a digitar dados, e é justamente aí que mora a principal barreira para quem está acostumado à liberdade da planilha.
Não. Construir aplicações e agentes com o Omni é gratuito e não consome créditos. Os créditos são consumidos quando os agentes executam trabalho sobre dados: analisar documentos, buscar na web, gerar conteúdo, traduzir ou gerar imagens. Essa separação tem uma consequência prática bastante útil: dá para iterar o desenho do sistema quantas vezes for necessário, testando descrições diferentes até chegar ao esquema adequado, sem que a fase de desenho dispute orçamento com a fase de operação. A recomendação que decorre disso é aproveitar essa gratuidade para experimentar de verdade com o modelo de dados antes de congelá-lo.
Não existe número fixo. Cada ação consome uma quantidade variável de créditos em função dos dados de entrada, do modelo selecionado e dos dados de saída. Um resumo curto sobre um registro pequeno com um modelo leve custa muito menos que a análise de um contrato extenso com um modelo potente que produz saída longa. Por isso a estimativa teórica é pouco confiável, e a única forma razoável de planejar é rodar o agente sobre uma amostra representativa de registros reais e extrapolar a partir do consumo observado. Vale fazer esse teste antes de ligar a execução automática a cada adição ou atualização de dados numa tabela de alto volume.
São compartilhados. A cota mensal corresponde a cada usuário pago conforme o plano, mas o conjunto é agrupado: no nível do espaço de trabalho nos planos Free e Team, e no nível da organização nos planos Business e Enterprise Scale. Não existe reserva por pessoa que impeça um usuário de consumir mais do que lhe caberia. A implicação operacional é que o orçamento de IA precisa de governança interna: se um time liga uma automação de alto volume sem avisar, ele pode esgotar a cota comum e deixar o restante sem capacidade. Combinar explicitamente quem pode acionar execuções automáticas em massa é tão importante quanto configurar os agentes corretamente.
A declaração oficial do Airtable é que os provedores de modelos nunca retêm os dados do cliente e que esses dados nunca são usados para treinar modelos. Além disso, clientes corporativos decidem quais modelos ficam habilitados, escolhendo entre provedores que incluem OpenAI, Anthropic, Meta e outros, o que permite alinhar o uso às políticas internas da organização. No plano administrativo, os administradores habilitam a IA no nível do espaço de trabalho e controlam a quais dados os agentes têm acesso, e toda a atividade fica governada e auditável. Para cenários com exigência mais estrita existe ainda a opção de armazenar os dados na União Europeia e, no nível corporativo, de manter dados em repouso com chaves de propriedade do próprio cliente.
Depende do plano, e o limite vale por base, não por espaço de trabalho. São mil registros por base no Free, cinquenta mil no Team e cento e vinte e cinco mil no Business. Esses números acabam antes do que a maioria imagina quando se trata de dado transacional, porque cada operação de negócio gera registro novo e tabelas de histórico crescem sem parar. Para conjuntos realmente grandes existe o HyperDB, que sincroniza e escala mesmo com mais de cem milhões de registros, mas trata-se de capacidade de nível corporativo e não de uma solução disponível para quem esbarra no teto num plano inferior. Vale projetar o crescimento anual de registros antes de comprometer um processo de alto volume.
Não para o uso normal. Modelar tabelas e relações, desenhar interfaces no Interface Designer e configurar automações de gatilho e ação acontece sem escrever código, e o Omni ainda permite gerar aplicações completas descrevendo-as em linguagem comum. Saber programar amplia o teto em dois pontos específicos: as automações aceitam JavaScript para lógica que a configuração declarativa não cobre, e a API web permite integrações sob medida seguindo semântica REST com objetos em JSON e códigos de status HTTP padrão. A barreira real para quem não é técnico não é o código, e sim o raciocínio relacional — entender vínculos, buscas e agregações é o que separa uma base que funciona de uma que virou planilha com outra aparência.
Em 4 de agosto de 2026 a Bending Spoons anunciou um acordo definitivo para adquirir o Airtable por um valor de empresa de 1,285 bilhão de dólares, mas a operação ainda não foi concluída. Ela está sujeita a aprovações regulatórias e às condições de fechamento habituais, com expectativa de conclusão ainda neste ano, e até lá as duas companhias continuam operando de forma independente. Produto, marca e domínio permanecem inalterados, então para o uso diário não há efeito imediato. Onde isso pesa é em decisões de contratação plurianual: depois do fechamento, a autoridade sobre preços e sobre o roteiro do produto pode mudar, então negociar condições de preço e conhecer as rotas de exportação de dados é precaução razoável.
A diferença de preço vai de vinte para quarenta e cinco dólares por usuário por mês na cobrança anual, e as diferenças funcionais relevantes são de escala e de controle. Em volume, o Team oferece cinquenta mil registros por base, vinte gigabytes de anexos e cem mil chamadas de API por espaço de trabalho por mês; o Business sobe para cento e vinte e cinco mil registros, cem gigabytes e chamadas de API ilimitadas. Ambos incluem um ano de histórico de revisões. Há ainda capacidades reservadas a níveis superiores, sobretudo no terreno de permissões, e o agrupamento de créditos de IA muda de nível de espaço de trabalho para nível de organização. A decisão costuma se resolver por duas perguntas: se a cota de chamadas de API vira gargalo para as integrações previstas e se o modelo de permissão exigido está disponível no Team.
Não. As aplicações geradas pelo Omni exigem revisão humana, e isso é orientação operacional, não formalidade. O esquema gerado costuma ser razoável na forma geral, mas os erros aparecem no detalhe: um campo tipado como texto livre onde deveria haver seleção fechada, uma relação montada na cardinalidade errada, uma automação com condição de disparo ampla demais. Esses problemas são triviais de corrigir no primeiro dia e muito caros depois que dezenas de milhares de registros já foram construídos sobre um modelo defeituoso. A prática correta é tratar a saída do Omni como um primeiro rascunho competente, que poupa a maior parte do trabalho mecânico, e dedicar em seguida uma revisão campo a campo antes de carregar dados reais.
