Небольшое продолжение про DuckLake. Если коротко: пока что на построение DuckLake как ODS/Staging слоя для данных я забил.

Забил из-за разных мелких проблем. То метаданные повредятся (останется ссылка на несуществующий уже parquet-файл), то казалось бы простая вьюха выжирает всю оперативку.

Первое время была пара случаев, что duckdb-процесс выжирал всю оперативку, пока за ним не прибегал OOM Killer (ставьте реакцию, кто понял, о ком это я). При выставлении внутренних лимитов на потребление памяти некоторые запросы плаксиво падали с жалобой, что с такими бюджетами лимитами они работать не готовы.

Значит ли это, что технология плохая? НЕТ. Технология прекрасна, красива и удобна. Просто пока сыровата. Это как когда-то с ранним ClickHouse, про который повелось, что он якобы не умеет в джойны.

COPY (
  SELECT
    order_id,
    customer_id,
    order_date,
    total_amount,
    ROUND(total_amount * 1.22, 2) AS amount_with_vat
  FROM postgres_query(
    'pg_orders_src',
    'SELECT * FROM public.orders WHERE status <> ''cancelled'''
  )
)
TO 'orders.parquet' (FORMAT PARQUET, COMPRESSION ZSTD);

Вот пример, когда в один запрос вы делаете практически весь ETL:
1) EXTRACT таблицы из Postgres (надо предварительно настроить ссылку на источник)
2) TRANSFORM внутри duckdb
3) LOAD (тут он COPY) в parquet-файл (который можно потом подтянуть в ClickHouse)

Как простенький ETL-инструмент duckdb уже весьма хорош.
Опять же, не путаем duckdb и DuckLake. Сам движок вполне себе зрелая технология, хотя разве что прожорливая на оперативку. Если вы, как и я, не любите pandas/Polars, то duckdb станет отличным решением!