A database engine that's
3-10x faster than SQLite

Where PowDB fits

PowDB is a single-writer embedded engine with truly parallel reads. Every writer takes the whole write-admission gate, and there is no MVCC. That shape decides where it shines.

PowQL vs SQL

PowQL reads left to right like a pipeline. No SELECT ... FROM ... WHERE juggling.

SELECT name, price
FROM Product
WHERE price > 10
ORDER BY name;

Product filter .price > 10
order .name
{ .name, .price }

SELECT AVG(age)
FROM User
WHERE city = 'NYC';

avg(User filter .city = "NYC"
{ .age })

SELECT status, COUNT(*)
FROM User
GROUP BY status
HAVING COUNT(*) > 5;

User group .status
having count(*) > 5
{ .status, count(*) }

INSERT INTO User (name, email, age)
VALUES ('Alice', 'alice@example.com', 30);

insert User {
  name := "Alice",
  email := "alice@example.com",
  age := 30
}

Embedded in Node — no server

The same engine, in-process. @zvndev/powdb-embedded is a native Node addon: open a database, run PowQL or SQL, no TCP, no daemon. It beats SQLite on writes once you pick a durability mode.

import { Database } from "@zvndev/powdb-embedded";

const db = Database.open("./data");

// "normal" = off-lock background fsync: much faster writes,
// a bounded crash-loss window. This closes the write gap vs SQLite.
db.setSyncMode("normal");

db.query('type User { required name: str, required email: str, age: int }');
db.query('insert User { name := "Alice", email := "alice@example.com", age := 30 }');

// PowQL
db.query('User filter .age > 25 { .name, .age }');

// ...or SQL, on the same handle — lowered to PowQL by the SQL frontend
db.querySql("SELECT name, age FROM User WHERE age > 25 ORDER BY age DESC");

Durability is a knob, not a fork: "full" fsyncs every commit (safest, the default), "normal" moves the fsync off the write lock for a bounded crash-loss window, and batching writes in a begin/commit transaction collapses a whole bulk load into a single fsync. That is how single-row insert throughput stops being fsync-bound.

When PowDB is not the right fit

PowDB is pre-1.0 and deliberately scoped. Be honest with yourself before adopting it:

• Pre-1.0 format stability -- the on-disk format may shift across minor versions. Pin versions and expect to re-import on upgrades until 1.0.
• No wire-protocol compatibility -- PowDB speaks a SQL subset (docs/SQL.md) through its own binary protocol and embedded API, not the Postgres or MySQL wire format. Off-the-shelf ORMs, BI dashboards, JDBC drivers, and DB browsers won't connect over the wire.
• Effectively single-node -- no sharding, no consensus, and no live replica tailing. Freshness across processes comes from snapshot refresh (restore a newer snapshot and swap, in seconds), not streaming replication. If you need live replication or sync across nodes, use Turso.
• No MVCC, no online backup -- a single writer takes the whole write-admission gate while parallel readers run; many concurrent clients sharing one read-write database is Postgres's territory. Backups (full, incremental, PITR) are offline-only today.

If any of those are dealbreakers, use SQLite -- and we say so plainly in PowDB vs SQLite: when to use which.