The embedded database that returns
shaped results, not flat rows

What PowQL does differently from SQL

Speed is not the interesting part of PowDB, and the benchmarks below are honest about where it loses. One of these four changes the answer you get. The other three change how much you have to write to get it.

SELECT a.tier, AVG(a.balance)
FROM Account a JOIN Ord o ON a.id = o.account_id
GROUP BY a.tier;
-- 15.0. The join repeats each account once per
-- order, so the account with 4 orders is counted
-- four times. The true average is 20.0.

Account as a join Ord as o on a.id = o.account_id
  group a.tier { a.tier, avg_bal: avg(a.balance) }
# 20.0. Each account contributes once.

# Opt back in to the joined-row number explicitly:
avg(raw a.balance)   # 15.0

SELECT u.name, o.total, o.product_id
FROM User u
LEFT JOIN "Order" o ON o.user_id = u.id;
-- Alice repeats once per order.
-- Cara (no orders) comes back as a row of NULLs.
-- The client regroups by hand.
--
-- A correlated subquery with json_group_array
-- gets the same shape as PowQL, as text.

User as u {
  u.name,
  orders: Order as o filter o.user_id = u.id
    { o.total, o.product_id }
}
# Alice, [{"product_id":101,"total":9.5},
#         {"product_id":102,"total":20.25}]
# Bob,   [{"product_id":null,"total":5.5}]
# Cara,  []

-- Rewrite the join condition every time
SELECT o.total, u.name
FROM "Order" o
JOIN User u ON o.user_id = u.id;

link Order.user -> User on user_id = id

Order as o { o.total, o.user.name }
User  as u { u.name, u.orders { .total } }

-- Filter, group, aggregate and order on a path
Post group .data->category {
  .data->category,
  total: sum(.data->amount)
}

# Index a scalar JSON path like any other column
alter Post add index (.data->published_at)

What is spelling and what is not. The nested shape itself is not exclusive: stock SQLite produces the same output, empty array for a childless parent included, with a correlated subquery and json_group_array(json_object(...)), and DuckDB, SurrealDB and several ORMs have their own spellings. What differs here is that PowDB owns the storage engine, the executor and the wire protocol, so the nested value crosses the wire as PJ1 binary and the client decodes that rather than parsing JSON text. It is a binary decode instead of a text parse, not the absence of a decode, and we have not published a benchmark of the difference. The aggregate above is the one item on this page that changes the answer rather than the typing.

Full detail: Symmetric aggregates, nested projections, entity links, and the PowQL reference.

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. Durability is a mode you pick, so batched writes can be made fast without giving up crash safety.

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 drops the cost from one fsync per row to roughly one per 64. 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 -- new on-disk format versions appear across minor versions. An older data directory always opens on a newer release (and upgrades lazily, without a rewrite). The reverse is not guaranteed: a directory written by a newer release opens on an older binary only while no format bump has fired, and once one has, the older binary refuses it. Pin versions, and read the stability policy before upgrading.
• 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.