AWS bought DuckLabs. Try DuckDB on a report, not on the SyBazar order table

Amazon signed for the company behind DuckDB on August 26. The project stays MIT. Here is the five-step check I would run before I let an analytics engine anywhere near a write path.

I saw AWS buy DuckLabs this morning and then I opened a SyBazar vendor GMV query. That was a slightly embarrassing order of events.

Amazon signed a definitive agreement for DuckLabs, the Amsterdam company behind DuckDB. The founders stay. The DuckDB Foundation keeps the IP. The license stays MIT. DuckDB already does more than a million downloads a day, and AWS has been wiring it into S3 Tables and SageMaker Lakehouse since 2024. The feed is arguing about whether this is Elasticsearch again. The useful sentence is smaller: DuckDB is an analytics engine you embed. It is not a replacement for the database that takes money.

We are not acquiring the DuckDB open-source project, which will remain free and open source under the independent DuckDB Foundation and available under the MIT license as it does today.

AWS, August 26 2026

SyBazar writes orders in Mongo. OnMission and LOMA write assignments in Postgres through Prisma. Lahebo writes subscriptions through Stripe. None of those tables should move because Amazon hired thirty people in Amsterdam.

Step 1: Name the job before you name the engine

DuckDB is SQLite for analytics. In-process. Columnar. Reads Parquet, CSV, and JSON without a server. It is fast on a laptop and on a Lambda. That is a report job. The SyBazar order table, the OnMission assignment row, and the Lahebo subscription status are OLTP jobs. If you conflate them, you will either lock a write path with a scan, or you will discover that DuckDB does not want to be your source of truth for a paid seat.

• Keep: Prisma, Postgres, and Mongo on creates, updates, and payments.
• Move: vendor GMV, assignment counts by org, “how many paid seats this month” — the queries that already feel like a warehouse.
• If the query has to be correct during checkout, it does not belong in DuckDB.

Step 2: Run one report on a file, not on production

Do not ATTACH your production DATABASE_URL. Dump the columns the report needs into CSV or Parquet, then query the file. If the number matches the dashboard you already distrust, you have a candidate. If it does not, you have a definition bug, not an engine bug.

import { DuckDBInstance } from "@duckdb/node-api";

export async function vendorGmv(csvPath: string) {
  const db = await DuckDBInstance.create(":memory:");
  const conn = await db.connect();
  const reader = await conn.runAndReadAll(
    `
    SELECT
      vendor_id,
      sum(total)::DOUBLE AS gmv,
      count(*)::INTEGER AS orders
    FROM read_csv_auto($path)
    WHERE status = 'paid'
    GROUP BY vendor_id
    ORDER BY gmv DESC
    LIMIT 50
    `,
    { path: csvPath },
  );

  return reader.getRowObjectsJS();
}

That is enough for a nightly vendor ranking. It is not enough to mark an order paid. The file can be a cron export from Mongo or a COPY from Postgres. The point is the write path never hears about DuckDB.

Step 3: If you must scan Postgres, scan a replica and stay read-only

DuckDB can ATTACH Postgres. That is convenient and it is how you accidentally run a GROUP BY on the primary that OnMission’s Prisma pool is already waiting on. Replica. Read-only. One report. Then stop.

INSTALL postgres;
LOAD postgres;

ATTACH 'dbname=onmission host=replica.internal'
  AS pg (TYPE postgres, READ_ONLY);

SELECT org_id, count(*) AS open_assignments
FROM pg.public.assignments
WHERE status = 'open'
GROUP BY org_id
ORDER BY open_assignments DESC;

Do not ATTACH production A replica with READ_ONLY is the whole mitigation. If you only have one Postgres box, export a file. DuckDB on the primary is still a scan of the assignment table, and Prisma will wait. I would rather a stale CSV than a locked HR board.

Step 4: Watch S3 Tables, not a rewrite of Redshift

The deal exists because AWS already put DuckDB next to S3 Tables and SageMaker Lakehouse. If SyBazar or Nepmeds already land events in S3, the next useful sentence is “query the files where they sit,” not “stand up a warehouse.” If you do not have a lake, you do not need a lake this weekend.

-- Only if the objects already exist.
-- Do not invent a lake to justify a headline.
SELECT
  vendor_id,
  sum(total) AS gmv
FROM read_parquet('s3://sybazar-exports/orders/*.parquet')
WHERE status = 'paid'
  AND paid_at >= DATE '2026-08-01'
GROUP BY vendor_id;

Step 5: What I would copy, and what I would not

• Copy: MIT license, Foundation stewardship, in-process analytics, files as the contract. That split is why I am not panicking.
• Copy: one report, one export, one memory database. Measure it against the Mongo aggregation or the Prisma groupBy you already hate.
• Do not copy: replacing Postgres or Mongo because Amazon hired the authors.
• Do not copy: ATTACH on the primary, DuckDB in the request that charges a card, or a rewrite of OnMission’s assignment list.
• Do not copy: waiting for AWS to “productize” a query you can already run on a CSV tonight.

The feed will move on. The useful part is boring and it travels. DuckDB is for the question you ask of last night’s data. Postgres and Mongo are for the row you write when someone pays. AWS buying the company does not change which of those jobs you are in.