Quem trabalha com JavaScript no servidor conhece o ritual: instalar o runtime, escolher o package manager, adicionar o framework HTTP, plugar o driver de banco, configurar o bundler, e rezar para que as versões não conflitem. O Bun vem tentando encurtar essa lista desde 2022. Com a versão 1.3, lançada em outubro de 2025, ele cortou boa parte dela de vez.

O release traz três mudanças que mudam o peso do runtime na balança: um cliente SQL unificado que fala com PostgreSQL, MySQL e SQLite sem dependências externas, um cliente Redis embutido com performance que dispensa o ioredis, e um dev server que roda frontend direto de um arquivo HTML. Junto veio a notícia de que a Anthropic adquiriu a Oven (empresa por trás do Bun) em dezembro de 2025 — a primeira aquisição da empresa, com o objetivo declarado de usar o Bun como infraestrutura do Claude Code.

O que muda no Bun 1.3

A versão anterior já tinha um cliente PostgreSQL embutido via Bun.sql. O 1.3 expande isso para MySQL/MariaDB e SQLite, tudo sob a mesma API. Redis ganhou um cliente nativo. O dev server agora aceita um arquivo .html como entry point e resolve TypeScript, JSX e CSS sem configuração. E o package manager ganhou scanning de segurança via uma API extensível.

Em números: o Bun reporta mais de 7 milhões de downloads mensais. A versão mais recente é a 1.3.3 (fevereiro de 2026), com correções de bugs e otimizações de performance. Empresas como Midjourney já usam o Bun em produção.

Mas o que interessa é o que cada uma entrega na prática.

SQL unificado sem drivers externos

O Bun.sql usa tagged template literals para queries. A sintaxe protege contra SQL injection por design — os parâmetros são interpolados como bindings, não como strings concatenadas.

Conexão com PostgreSQL:

import { SQL } from "bun";

const sql = new SQL("postgres://user:pass@localhost:5432/mydb");
const users = await sql`SELECT id, name FROM users WHERE active = ${true}`;

A mesma API funciona com MySQL:

import { SQL } from "bun";

const mysql = new SQL("mysql://user:pass@localhost:3306/mydb");
const orders = await mysql`SELECT * FROM orders WHERE total > ${100}`;

E com SQLite:

import { SQL } from "bun";

const db = new SQL("sqlite://app.db");
const posts = await db`SELECT * FROM posts WHERE published = ${1}`;

Três bancos, mesma interface. Sem pg, sem mysql2, sem better-sqlite3 no package.json. O connection pooling é lazy — nenhuma conexão é aberta até a primeira query. Transações usam callbacks com rollback automático em caso de erro:

await sql.begin(async (tx) => {
  await tx`INSERT INTO accounts (name) VALUES (${'Alice'})`;
  await tx`UPDATE balances SET amount = amount - 100 WHERE account = ${'Alice'}`;
});

Existem diferenças entre os bancos que a API não esconde. MySQL não suporta a cláusula RETURNING — você precisa usar result.lastInsertRowid ou fazer um SELECT separado. PostgreSQL tem arrays nativos; MySQL e SQLite não. O sql.array() só funciona com PostgreSQL. São detalhes que aparecem quando você porta queries entre bancos, mas a superfície da API continua a mesma.

Uma coisa que me chama atenção: a ideia de que um runtime deveria embutir clientes de banco de dados é controversa. O Node.js sempre delegou isso para o ecossistema npm. O Bun está apostando que menos dependências externas compensam o aumento de superfície do core. Para projetos menores e prototipagem, a conveniência é real. Para projetos grandes com necessidades específicas (connection pooling avançado, migrations, query builders), ferramentas como Drizzle e Prisma continuam fazendo sentido.

Redis embutido no runtime

O cliente Redis é novo no 1.3 e segue a mesma filosofia: zero dependências, API nativa.

import { RedisClient } from "bun";

const redis = new RedisClient("redis://localhost:6379");
await redis.set("session:abc", JSON.stringify({ userId: 42 }));
const session = await redis.get("session:abc");

Suporta 66 comandos incluindo hashes (HSET/HGET), listas (LPUSH/LRANGE) e sets. Também funciona com Valkey, o fork BSD do Redis mantido pela Linux Foundation. Reconexão automática, timeouts por comando e fila de mensagens vêm configurados por padrão.

O Bun afirma que o cliente nativo é 7.9x mais rápido que o ioredis. Benchmarks próprios sempre merecem um grão de sal, mas a vantagem de não passar por uma camada JavaScript pura (o ioredis é JS rodando sobre o Node.js) é estrutural. O cliente do Bun é implementado em Zig, a mesma linguagem do runtime.

Suporte a clusters, streams e Lua scripting ainda está em desenvolvimento. Se o seu caso de uso depende de Redis Cluster em produção, o ioredis ou o node-redis continuam sendo a escolha segura por enquanto.

Frontend direto do HTML

Essa feature muda o fluxo de quem precisa de um dev server rápido. Em vez de configurar Vite, Webpack ou qualquer outro bundler:

bun index.html

O Bun lê o HTML, resolve os scripts e styles referenciados, compila TypeScript e JSX automaticamente, e serve tudo com Hot Module Replacement. React Fast Refresh funciona sem configuração — você edita um componente, salva, e o estado do componente é preservado no browser.

O file watching usa APIs nativas do sistema operacional: kqueue no macOS e inotify no Linux. Não há polling.

Para build de produção:

bun build ./index.html --production

É tentador comparar com o Vite, que também oferece um dev server rápido com HMR. A diferença é que o Vite precisa de um vite.config.ts, um package.json com dependências, e um index.html que aponta para o entry point do JS. O Bun elimina as duas primeiras etapas. Para protótipos, demos, e projetos menores, essa redução de fricção é significativa. Para aplicações com necessidades de build complexas (code splitting granular, SSR, plugins customizados), o Vite continua mais maduro.

O ecossistema ao redor

Além das três features principais, o 1.3 trouxe melhorias no ecossistema do package manager e do servidor HTTP.

O Security Scanner API permite que ferramentas externas analisem pacotes durante a instalação. O Bun fez parceria com a Socket para lançar o @socketsecurity/bun-security-scanner, que detecta CVEs conhecidos, pacotes maliciosos e problemas de licença. A configuração fica no bunfig.toml.

O servidor HTTP ganhou uma Cookie API nativa com interface similar a Map. O request.cookies só faz parsing do header quando acessado — zero overhead se você não usa cookies. Quando você modifica cookies, os headers Set-Cookie são adicionados automaticamente na resposta.

Bun.serve({
  fetch(request) {
    const theme = request.cookies.get("theme") || "dark";
    request.cookies.set("visited", "true", { httpOnly: true });
    return new Response(`Tema: ${theme}`);
  },
});

O package manager agora suporta catalogs de dependências para monorepos (inspirado no pnpm), bun update --interactive para atualização seletiva, e bun why para explicar cadeias de dependências. Instalações isoladas são o padrão em workspaces, impedindo que pacotes acessem dependências não-declaradas.

Na compatibilidade com Node.js, o 1.3 adicionou suporte ao módulo vm e ao node:test (usando bun:test por baixo). Testes escritos para Node.js rodam no Bun com a performance do test runner nativo.

Conclusão

O Bun 1.3 não é um runtime que tenta ser um pouco melhor que o Node.js em cada coisa. Ele está tentando ser a coisa inteira: runtime, bundler, package manager, dev server, cliente de banco, cliente de cache. Para um projeto que está começando do zero e não precisa de customização pesada, a proposta de eliminar 8-12 dependências npm de um stack típico é concreta.

A aquisição pela Anthropic adiciona uma camada nova à história. O Bun agora tem um funding significativo e um caso de uso estratégico (infraestrutura do Claude Code). Isso traz estabilidade financeira, mas também levanta a questão de quanto da roadmap será direcionada para necessidades da Anthropic versus necessidades da comunidade open source. O projeto continua MIT e desenvolvido publicamente — por enquanto, nada mudou nesse front.

Se você está em um projeto Node.js estável com dependências bem conhecidas, migrar por migrar não faz sentido. Se está avaliando stacks para algo novo e a redução de dependências e a velocidade de setup importam, vale testar o Bun 1.3 num projeto piloto.

Referências pesquisadas nesta publicação