Em nosso anterior weblogapresentamos o Lakebase, a arquitetura de banco de dados de terceira geração que separa fundamentalmente armazenamento e computação. Neste weblog, exploramos uma consequência crítica dessa mudança: como os agentes de IA estão mudando o ciclo de vida de desenvolvimento de software program e de que tipo de bancos de dados os agentes de IA realmente precisam?
O ciclo de vida de desenvolvimento de software program está passando por uma transformação radical. Os LLMs possibilitaram uma nova geração de estruturas de agente que podem analisar requisitos, escrever código, executar testes, implantar serviços e refinar aplicativos iterativamente, tudo em velocidade recorde. Como resultado, o custo marginal de construção e implementação de aplicações está a cair vertiginosamente.
Embora ainda estejamos nos estágios iniciais do desenvolvimento de software program de agência, observamos consistentemente, tanto dentro do Databricks quanto entre nossa base de clientes, que a taxa de experimentação está acelerando e o grande quantity de aplicativos sendo construídos está explodindo. À medida que o mundo faz a transição do software program artesanal para o desenvolvimento de software program de agência, identificamos três tendências emergentes que redefinirão em conjunto os requisitos dos sistemas de banco de dados modernos:
- O desenvolvimento de software program passará de um processo convencional lento e linear para um processo evolutivo rápido.
- O software program se tornará mais valioso em geral, mas o valor de cada aplicativo particular person cairá à medida que o custo marginal para desenvolver software program diminuir. Isto significa que precisamos de infra-estruturas que possam apoiar o desenvolvimento de software program com um custo marginal mínimo. Crucialmente, a arquitetura também deve levar em conta o fato de que qualquer um desses bancos de dados pequenos e efêmeros pode se tornar um sistema de produção com muito tráfego, tornando a capacidade de suportar o crescimento contínuo e elástico um requisito arquitetônico basic.
- Os ecossistemas abertos tornar-se-ão um requisito operacional estrito e não apenas uma preferência.
Aqui está uma visão mais aprofundada de cada uma dessas tendências e como o Lakebase foi projetado exclusivamente para apoiá-las.
Desenvolvimento rápido e evolutivo de software program
Como grande parte do ciclo de vida de desenvolvimento de software program period historicamente muito dispendioso (escrever código, testes, operações), construir e operar um novo aplicativo exigia um investimento significativo em engenharia. Consequentemente, o desenvolvimento de software program tradicional foi otimizado para um planejamento cuidadoso e um processo relativamente linear.
Os agentes mudam essa dinâmica. Os aplicativos agora podem ser gerados, modificados e reimplantados em minutos. Em vez de construir um sistema cuidadosamente projetado, os desenvolvedores e agentes exploram cada vez mais grandes espaços de implementações possíveis. O desenvolvimento começa a se assemelhar a um algoritmo evolutivo:
- Gere uma versão inicial de um aplicativo.
- Crie variantes rapidamente com diferentes esquemas, prompts ou lógicas.
- Avalie os resultados.
- Proceed o desenvolvimento a partir das versões de maior sucesso.
Dependendo da complexidade, cada iteração evolutiva pode durar de segundos a horas, o que é 100x a 1000x mais rápido do que os ciclos de desenvolvimento pré-LLM. Na verdade, nossa telemetria dos ambientes de produção Lakebase mostra que, em média, cada projeto de banco de dados tem aproximadamente 10 ramificações e alguns bancos de dados com ramificações aninhadas atingindo profundidades de mais de 500 iterações (ou seja, 500 iterações na evolução).
A infraestrutura de código como o Git já suporta muito bem esse fluxo de trabalho. Desenvolvedores ou agentes podem criar uma ramificação da base de código com git checkout -b imediatamente. No entanto, a infraestrutura de banco de dados legada não oferece uma maneira rápida e econômica de ramificar o estado do banco de dados.
Lakebase foi projetado para oferecer suporte nativo a esse fluxo de trabalho evolutivo de agente. Os agentes podem criar uma ramificação de um banco de dados de produção ou de teste instantaneamente e com custo quase zero. Como o Lakebase usa um mecanismo de ramificação de cópia na gravação de metadados O(1) na camada de armazenamento, nenhuma cópia física cara de dados é necessária. Você simplesmente ramifica os dados junto com o código e paga apenas pela computação do banco de dados durante o experimento.
Sensibilidade ao custo
Como mencionado anteriormente, embora o software program se torne globalmente mais valioso, o valor de cada aplicação particular person irá despencar à medida que o custo marginal para desenvolver software program diminuir. Muitos serviços gerados por agentes são pequenas ferramentas internas, protótipos ou fluxos de trabalho restritos. Eles podem ser executados apenas ocasionalmente ou atender cargas de trabalho altamente intermitentes e orientadas por eventos.
Neste mundo, precisamos de infraestrutura que possa suportar o desenvolvimento de novos softwares a um custo marginal/incremental mínimo. Qualquer banco de dados que imponha centenas de dólares por mês como preço base é impossível de justificar se o próprio aplicativo fornecer valor limitado ou experimental. Nossos dados mostram que, para cerca de metade desses aplicativos de agente, o tempo de vida útil da computação do banco de dados é inferior a ten segundos.
Os bancos de dados tradicionais foram projetados como componentes de infraestrutura sempre ativos, com provisionamento fixo e sobrecarga operacional. Esse modelo se adapta a aplicações grandes e estáveis, mas falha economicamente quando as aplicações são numerosas, efêmeras e de curta duração.
A natureza elástica e sem servidor do Lakebase aborda diretamente esse imperativo de custo. Ao desacoplar totalmente as instâncias de computação da camada de armazenamento, o Lakebase pode dimensionar automaticamente a computação do banco de dados com base na carga em menos de um segundo. Crucialmente, ele também reduz o banco de dados a zero quando não é utilizado, eliminando completamente o custo mínimo e alcançando custos de inatividade quase nulos.
Crescendo de pequeno para grande
A natureza do desenvolvimento orientado por agentes significa que um enorme quantity de bancos de dados pequenos e efêmeros são constantemente criados para testes, prototipagem e fluxos de trabalho restritos. O desafio arquitectónico essential é que os programadores, e os próprios agentes, não conseguem prever quais destas aplicações nascentes irão subitamente decolar e exigir uma escala de produção massiva.
A arquitetura do banco de dados deve, portanto, suportar inerentemente crescimento contínuo e elástico desde uma instância minúscula e de baixo custo até um sistema de produção em grande escala com tráfego intenso. Essa transição deve ocorrer sem exigir nenhuma reformulação handbook, provisionamento ou etapas complexas de migração do usuário. A arquitetura por si só deve lidar com a evolução, tornando a capacidade de escalar instantaneamente de quase zero até uma capacidade massiva um requisito basic para um mundo onde a exploração de agentes é o modelo de desenvolvimento padrão.
Ecossistemas de código aberto
Os sistemas agênticos derivam suas capacidades de LLMs treinados em extensos corpora de código-fonte e documentação técnica disponíveis publicamente. Essa tendência de treinamento proporciona a eles uma familiaridade operacional profunda com ecossistemas de código aberto, APIs e semântica de erros.
Bancos de dados como o Postgres estão profundamente enraizados no mundo do código aberto. Suas interfaces, comportamentos e códigos de erro aparecem nos dados de treinamento com os quais os modelos modernos aprendem. Como resultado, os agentes podem gerar consultas, esquemas e integrações para eles de forma muito mais confiável. Os bancos de dados proprietários enfrentam uma desvantagem inerente porque os agentes simplesmente não possuem contexto suficiente para operá-los de forma eficaz.
Para o desenvolvimento orientado por agentes, a abertura não é mais apenas uma preferência filosófica – é um requisito prático para uma automação confiável. Mas esse requisito deve ir além da interface de consulta; ele deve atingir a própria camada de armazenamento. Embora os bancos de dados em nuvem de segunda geração possam usar mecanismos de execução de código aberto, eles ainda bloqueiam seus dados em formatos de armazenamento internos proprietários.
Lakebase é baseado no Postgres, mas leva a abertura um passo adiante. Ele armazena dados em formatos de página Postgres abertos e padrão diretamente no armazenamento de objetos em nuvem (o information lake). Isso permite que agentes, mecanismos analíticos externos e novas ferramentas interajam com os dados de forma nativa, sem nunca serem estrangulados por um único mecanismo de computação proprietário.
Bancos de dados para a Period Agentic
A mudança não é hipotética – já está em curso. No serviço Lakebase da Databricks, os agentes de IA agora criam cerca de 4x mais bancos de dados do que usuários humanos.
Este ponto de dados captura as tendências descritas acima em um único gráfico. Os agentes são criadores prolíficos de ambientes de banco de dados – criando instâncias para experimentos, ramificando para testes e descartando-as quando terminarem. A infraestrutura que serve estas cargas de trabalho deve apoiar este padrão económica e operacionalmente.
Propriedades como eficiência de custos, agilidade e abertura sempre foram desejáveis. Mas a ascensão do desenvolvimento de software program de agência transformou-os de itens interessantes em requisitos fundamentais. Bancos de dados que impõem altos custos mínimos, não possuem ramificações primitivas ou bloqueiam dados em formatos proprietários ficarão cada vez mais fora de sintonia com a forma como o software program está sendo construído.
Este é precisamente o espaço de design do Lakebase. Ele foi construído para as realidades econômicas e técnicas específicas que o desenvolvimento impulsionado pela IA cria: ramificação evolutiva a custo zero, verdadeira elasticidade de escala a zero, armazenamento aberto do Postgres no lago e operações autogerenciadas. À medida que os agentes participam cada vez mais na construção e evolução de software program, as bases de dados mais adequadas para este novo mundo são aquelas concebidas para experimentação, abertura e elasticidade desde o início.