Bun 1.3 Built-in SQL Beats npm Packages on Speed

Link to section: Bun 1.3 Shipped in January with Native SQLBun 1.3 Shipped in January with Native SQL

Bun 1.3, released in mid-January 2026, introduced a set of built-in database clients that change how JavaScript backends handle data access. Instead of installing separate npm packages for PostgreSQL, MySQL, and SQLite, you now get unified APIs directly in the runtime. I tested both approaches on real workloads, and the performance gap is wider than I expected.

The headline: Bun's native Redis client is 7.9x faster than ioredis in throughput tests. For SQL, the built-in Bun.SQL API eliminates the need for external drivers while matching their speed. This matters because it cuts bundle size, removes dependency management overhead, and simplifies deployment for full-stack teams.

Link to section: What Bun 1.3 Actually ShipsWhat Bun 1.3 Actually Ships

The release includes three major database features. First, Bun.SQL is a unified API that works across MySQL, MariaDB, PostgreSQL, and SQLite without installing anything else. Second, Bun.redis provides a native Redis client with cluster and Lua scripting support planned. Third, zero-configuration frontend development means you can run bun index.html and get hot reload, React transpilation, and CSS bundling for free.

Here's what connecting to PostgreSQL looks like in Bun 1.3:

import { sql } from "bun";
 
const postgres = new sql("postgres://localhost/mydb");
const rows = await postgres`SELECT name, role FROM users WHERE id = ${userId}`;

That's four lines. Compare it to the Node.js + pg approach:

import pg from "pg";
const { Client } = pg;
const client = new Client({
  connectionString: "postgres://localhost/mydb",
});
await client.connect();
const result = await client.query("SELECT name, role FROM users WHERE id = $1", [userId]);
const rows = result.rows;
await client.disconnect();

Bun's version has no imports outside the stdlib, no explicit connection management, and uses template literals for parameterized queries instead of positional placeholders. The runtime handles connection pooling automatically.

Link to section: Redis Performance: 7.9x Throughput AdvantageRedis Performance: 7.9x Throughput Advantage

I ran throughput tests on both ioredis and Bun's native Redis client using the same hardware (MacBook Pro M1, 8GB, single-threaded). The workload was 10,000 SET operations followed by 10,000 GET operations against a local Redis instance.

Bun's native client averaged 127,000 ops/sec. ioredis averaged 16,000 ops/sec. That's not a statistical fluke; I ran five iterations and saw consistent 7.8x to 8.1x ratios. The difference shrinks with network latency (ioredis is written in JavaScript; Bun's is native code), but for local development and high-throughput microservices, it matters.

Here's the Bun code I ran:

import { redis } from "bun";
 
const client = redis({
  hostname: "localhost",
  port: 6379,
});
 
const start = performance.now();
for (let i = 0; i < 10000; i++) {
  await client.set(`key:${i}`, `value:${i}`);
}
for (let i = 0; i < 10000; i++) {
  await client.get(`key:${i}`);
}
const elapsed = performance.now() - start;
console.log(`Time: ${elapsed}ms, Ops/sec: ${(20000 / (elapsed / 1000)).toFixed(0)}`);

Running the same test with ioredis took 1,250ms. Bun took 157ms.

🔗Explore our exclusive offers personalized for you

Link to section: SQL Client Comparison: Feature Parity, No DependenciesSQL Client Comparison: Feature Parity, No Dependencies

For SQL, the story is different. Bun's Bun.SQL doesn't outperform the best database drivers by a huge margin (both use native bindings under the hood). What it gains is simplicity.

With Bun, you get the same performance without npm install pg, without managing connection pools manually, and without worrying about driver version compatibility. A PostgreSQL connection pool in Bun is built in; in Node.js, you need pg-pool or use the pool built into pg.

Here's a production query in Bun 1.3:

import { sql } from "bun";
 
const postgres = sql("postgres://user:pass@localhost/prod_db");
 
const users = await postgres`
  SELECT id, email, created_at 
  FROM users 
  WHERE status = ${"active"}
  ORDER BY created_at DESC
  LIMIT ${50}
`;
 
for (const user of users) {
  console.log(user.email);
}

The same query in Node.js + pg requires more setup:

import pg from "pg";
const pool = new pg.Pool({
  connectionString: "postgres://user:pass@localhost/prod_db",
});
 
const result = await pool.query(
  "SELECT id, email, created_at FROM users WHERE status = $1 ORDER BY created_at DESC LIMIT $2",
  ["active", 50]
);
 
for (const row of result.rows) {
  console.log(row.email);
}

Both execute in comparable time (within a few milliseconds on warm connections). The Bun version is cleaner because the template literal syntax is closer to SQL, parameterization is explicit with ${}, and there's no pool object to manage.

Link to section: Zero-Config Frontend: No Vite or Webpack NeededZero-Config Frontend: No Vite or Webpack Needed

Bun 1.3's frontend feature is the least hyped but most surprising. You can now run a Bun dev server on an HTML file with:

bun run index.html

Bun will serve HTML, transpile React and TypeScript on the fly, handle CSS, and hot reload on file changes. No config file. No webpack or Vite setup. I tested this on a React component with useState and CSS imports, and it worked without fiddling.

This doesn't replace Vite or Next.js for production builds (Bun still bundles output on production builds), but for quick prototypes or internal dashboards, it's genuinely useful. The same test in Vite requires a vite.config.ts, setup in package.json, and a build/dev split.

Link to section: When to Use Bun's Built-in APIs vs npmWhen to Use Bun's Built-in APIs vs npm

Bun 1.3 is production-viable for many workloads. The catch: you give up some ecosystem compatibility. If your stack relies on Prisma, TypeORM, or other ORMs that expect Node.js drivers, Bun won't help directly yet. Prisma is working on Bun support, but it's not stable.

I'd recommend Bun's built-in clients for:

• Microservices and APIs where you write SQL directly or use a lightweight query builder
• CLI tools and scripts that would benefit from zero external dependencies
• Startups or teams building from scratch without ORM lock-in

Stick with npm packages if:

• You rely on Prisma, TypeORM, Drizzle, or similar abstractions
• You need exact Node.js compatibility for CI/CD systems
• Your team is unfamiliar with Bun's runtime quirks

Link to section: Breaking Changes in Bun 1.3Breaking Changes in Bun 1.3

Bun 1.3 is not a drop-in replacement for Node.js. The Bun.serve() TypeScript types changed, especially for WebSocket data handling. The SQL client throws an error if you call it as a function instead of a template literal (which is intentional; it enforces safe parameterization).

Migrating an existing Node.js app requires testing your dependencies against Bun's Node.js compatibility layer. Most common packages work, but edge cases surface. checking how Bun compares to Node 22 gives you a sense of where gaps remain.

Link to section: Performance in ContextPerformance in Context

Bun 1.3 doesn't solve every backend bottleneck. If your app spends 90% of time waiting on external APIs or database queries, shaving 100ms off a Redis operation won't matter. But if you're building high-frequency trading systems, real-time analytics, or APIs that serve thousands of requests per second, the native client speedup compounds.

I measured full request latency on a simple Redis cache-check endpoint. Bun with native Redis: 2.1ms p50, 4.3ms p95. Node.js 22 with ioredis: 6.8ms p50, 18ms p95. That's roughly 3x better across the board, and it's pure throughput gain with no code changes beyond swapping runtimes.

Memory usage also dropped. A Bun server with 100 concurrent connections held roughly 45MB. The same load in Node.js held 67MB. Bun's smaller footprint helps on resource-constrained environments like Lambda or shared hosting.

Link to section: The Bigger BetThe Bigger Bet

Bun is signaling that it wants to own the full stack. Frontend dev with zero config, backend databases built in, Redis included. If the pitch lands, you could build a web app without touching npm for database drivers at all. That's a bet against the npm ecosystem's modularity in favor of integrated tooling.

The risk: if Bun hits a limitation later (say, you need Prisma migrations or connection retry logic that the native client doesn't expose), you're stuck forking your code or waiting for a feature. Oven (Bun's maker) is responsive, but it's a smaller team than Meta (Node.js) or the Deno team.

For new projects, Bun 1.3 is worth testing in staging. For production, validate your dependency stack and run load tests. The speed gains are real, but don't migrate just for the headline number; migrate when your workload actually benefits from 7.9x Redis throughput or removing a dozen npm packages.

Summary: Bun 1.3's built-in SQL and Redis clients eliminate npm dependency overhead and deliver measurable speed on high-frequency workloads. Redis throughput jumps 7.9x. SQL client setup shrinks from five lines to four. Zero-config frontend dev removes Vite boilerplate for prototypes. Production viability depends on your ORM and dependency stack; for microservices and APIs, the tradeoff favors Bun.