DuckDB or Postgres?

01 / The customer decision

Two jobs can lead to different answers

In Chapter 1, you compared two ways to add numbers. Now we’ll use the same method to compare two database engines: programs that store data and answer requests about it. A request to retrieve or calculate information is called a query.

Imagine a sales operations team choosing a database for an order screen and a revenue dashboard. The screen needs one known order; the dashboard needs totals by month and region. We’ll use these jobs because they ask the engines to do different kinds of work, while keeping the example small enough to inspect.

Which engine completes each job sooner on your device? You’ll run both queries on the same orders, check the returned values, and compare the times. This gives you a first finding to investigate in later chapters, where we’ll examine configuration, customer usage and the reliability of the measurements.

DuckDB is often used for analytical work: reading and summarising sets of data. Postgres is a general-purpose relational database used for many applications. Those descriptions suggest questions to investigate; they do not supply a result for this experiment.

Here you will run DuckDB-Wasm and PGlite, a WebAssembly build of Postgres. The introduction explains why the labs use WebAssembly. Both engines use SQL, the language used to ask a database for rows. Everything runs locally in this tab; a customer’s server deployment needs its own measurements.

02 / Worked example

Follow an order through the comparison

A table stores rows of records and named columns. Our table has one row per order. A schema defines its column names and types. Every value here is an integer, including revenue in cents, so decimal rounding and time zones cannot change the answer.

An index is an additional structure that can help locate rows without examining the whole table. This first baseline creates no indexes or constraints in either engine. The lookup therefore asks how these configurations find one order; it is not a test of a tuned, indexed application. Chapter 3 will help you decide what equivalent work requires.

CREATE TABLE orders (
  order_id INTEGER,
  month_id INTEGER,
  region_id INTEGER,
  amount_cents INTEGER
);

const id = offset + 1;
const row = [
  id,
  Math.floor(offset / 4) % 12 + 1,
  offset % 4 + 1,
  id * 37 % 10000 + 100
];

BEGIN;
-- CREATE TABLE above, then INSERT INTO orders VALUES (...), (...);
-- One INSERT statement per 500 generated rows, in ID order.
COMMIT;

-- Timed separately after loading:
ANALYZE orders;

Enable JavaScript to expand the deterministic recipe into all INSERT statements.

03 / Your experiment

Inspect the requests. Run the comparison.

Start with 2,000 orders. Read the two requests below and, if you like, write a prediction. Then run again with 20,000 orders. Does the relationship between the engines change when there is more work?

SELECT order_id, month_id, region_id, amount_cents
FROM orders WHERE order_id = 1000;

SELECT month_id, region_id,
       CAST(SUM(amount_cents) AS BIGINT) AS revenue_cents
FROM orders
GROUP BY month_id, region_id
ORDER BY month_id, region_id;

Enable JavaScript to inspect all reference rows.

04 / Read your result

First check what the clock included

The useful number depends on where you start and stop the clock. Here, each sample measures one complete browser request: from sending the SQL to receiving all returned fields as plain integer strings.

DuckDB returns an Arrow table, a column-oriented result format; PGlite returns JavaScript rows. Their wrappers take different paths to produce the same plain result. Wrapper work stays inside this common boundary and can dominate tiny requests, so these timings describe the whole browser request rather than engine execution alone.

Before reading the table as a recommendation: how would the decision change if the order screen needs an index, or the dashboard runs only once after each data load? Query time alone cannot answer either question.

05 / Keep the comparison honest

The same data is only the beginning

Later chapters turn these limits into design choices: equivalent work, representative workloads, trustworthy measurement, uncertainty and demand. For now, learning to name a missing condition is part of doing the benchmark well.

06 / Independent practice

Write a claim someone else can check

Complete two runs, one at each size. Write an initial finding for the sales operations team that a colleague could reproduce. Use your measurements to make a conditional claim.

1. Name the conditions. Include the query, fixture size, browser builds and warm request boundary.
2. Point to the evidence. Describe the observed result and its spread. Keep query time separate from startup and loading.
3. Choose the next check. Name one condition that could change the customer’s decision, and explain why.

Saved as a draft on this device when storage is available; included with the selected run at export time. A measured record always keeps its original SQL, configuration and samples.

07 / Sources and method

Keep the experiment open to inspection

The engine code, worker scripts, data bundle and WebAssembly binaries are served by this site. No CDN or database backend is used. Fresh workers isolate each run; Stop, time limits and page exit terminate them. Each successful run closes both engines before releasing its workers.

• DuckDB-Wasm documentation · npm package @duckdb/duckdb-wasm 1.32.0
• PGlite documentation · npm package @electric-sql/pglite 0.5.13
• Detailed measurement contract and reproduction
• Engine source and licence notices