# v0.64.0 — DuckLake Ecosystem Phase 1

> **Full details:** [plans/ecosystem/PLAN_DUCKLAKE.md](../plans/ecosystem/PLAN_DUCKLAKE.md)

## What's New

v0.64.0 is a pure documentation, demo, and community release — no changes to
the extension itself. It launches pg_trickle as a recognised first-class
participant in the DuckLake ecosystem, establishing the narrative that
pg_trickle is the incremental view maintenance engine that every
PostgreSQL-backed DuckLake deployment has been waiting for.

DuckLake v1.0 (released April 2026) stores all its bookkeeping in a standard
SQL database — most commonly PostgreSQL. pg_trickle lives in that same
PostgreSQL instance. That co-location is the architectural superpower that this
release makes visible to the world.

DuckLake's own public roadmap lists "Materialized views and incremental
maintenance" as a future item explicitly tagged *"looking for funding."*
This release plants the flag: pg_trickle already does this, it works today, and
here is how.

## Deliverables

### Tutorials

**Tutorial T-1: "Real-Time Dashboards on Your Data Lake"**  
DuckDB writes synthetic events into a DuckLake table at high throughput.
pg_trickle stream tables compute per-minute and per-user aggregations over the
lake data using the existing foreign-table polling path. A Grafana dashboard
connected to the PostgreSQL stream-table results updates in sub-second latency.
The tutorial covers setup, the stream-table SQL, and a comparison of query times
before and after.

**Tutorial T-2: "The Modern Data Stack in One Box"**  
A reference architecture that replaces the classic five-system
Debezium-Kafka-Flink-Iceberg pipeline with a single PostgreSQL instance plus an
S3 bucket. OLTP writes in PostgreSQL, pg_trickle computes real-time
aggregations, DuckLake stores the history in Parquet on S3, DuckDB handles
ad-hoc analytics. No Kafka, no Airflow, no JVM, no separate clusters.

**Tutorial T-3: "Monitoring Your DuckLake with pg_trickle"**  
DuckLake's ~28 metadata tables live in PostgreSQL and are rich with operational
signals. This tutorial builds a set of stream tables that deliver real-time
operational visibility: snapshot rate per minute, tables with many small files
(compaction candidates), per-tenant write activity for multi-tenant deployments,
and storage growth curves. Includes a Grafana dashboard definition.

### Blog Posts

**Blog B-1: "Why pg_trickle + DuckLake Is the Missing Piece for Lakehouse IVM"**  
Thought-leadership post aimed at Hacker News, /r/dataengineering, and the dbt
Slack. Frames the lakehouse-IVM gap, shows why existing solutions (Materialize,
RisingWave, Flink) require separate infrastructure, and explains how pg_trickle
fills the gap from inside the catalog database — the infrastructure DuckLake
already requires. Links to DuckLake's own roadmap item as the anchor.

**Blog B-2: "DuckLake's `table_changes()` Meets pg_trickle's DVM Engine"**  
Technical deep-dive for the systems-programming audience. Explains DuckLake's
change-feed API (`table_changes()`, `table_insertions()`, `table_deletions()`),
maps its output format row-by-row to pg_trickle's internal change-buffer
schema, and discusses why DuckLake's stable `rowid` column makes it one of the
cleanest CDC sources imaginable for differential IVM.

### Documentation

**Docs D-1: DuckLake examples in `foreign-table-sources.md`**  
Adds a dedicated DuckLake section to the existing foreign-table-sources
reference page. Covers attaching a DuckLake-managed table as a PostgreSQL
foreign table, enabling `pg_trickle.foreign_table_polling`, and wrapping it
in a stream table. Includes a working code sample with schema, server
definition, and `create_stream_table` call.

### Demos

**Demo A: "The Five-Second Funnel"**  
A self-contained `docker-compose up` demo. One container runs PostgreSQL with
pg_trickle and a DuckLake catalog. A second container runs a DuckDB load
generator writing synthetic e-commerce events. A third container runs Grafana.
The Grafana dashboard shows a live visit→product→cart→checkout→purchase funnel
updating every five seconds from a pg_trickle stream table. Designed to be
shared at conference talks and on social media; runs on any developer laptop.

**Demo D: "DuckLake Observability in a Box"**  
A companion to Tutorial T-3. A pre-packaged `docker-compose` stack plus a
single SQL initialisation script. The user attaches it to an existing DuckLake
PostgreSQL catalog, runs `psql -f init_monitoring.sql`, and immediately has a
production-quality Grafana observability dashboard with no further configuration.
Goal: five minutes from `git clone` to operational visibility.

### Community

**Community C-1: Named-user outreach**  
Direct contact with the DuckLake production users listed on the DuckLake
homepage — PostHog, Windmill, Ascend.io, Sliplane, locals.com, and Media
Cluster Norway — with a tailored pitch explaining how pg_trickle solves the
incremental-aggregation problem they each face on top of their existing DuckLake
deployment.

**Community C-2: DuckCon and PGConf talk submissions**  
CFP submissions: "pg_trickle as the IVM layer for DuckLake" for DuckCon, and
"Sub-second materialized views on your data lake" for PGConf EU and PGCon.

**Community C-3: DuckLake GitHub engagement**  
Open a Discussion on `duckdb/ducklake` summarising the integration architecture
and offering to co-author a "pg_trickle + DuckLake reference architecture" page
on the DuckLake documentation site.

## Why These Additions Belong in v0.64.0

The original v0.64.0 plan had five documentation deliverables. The deeper
research conducted during planning uncovered three opportunities that are still
zero-code but substantially increase the release's impact:

- **Demo A and Demo D** are runnable artefacts rather than prose. They give the
  DuckLake community something to `git clone` and run, which is far more
  persuasive than reading a tutorial.
- **Blog B-2** (the `table_changes()` technical deep-dive) hits a different and
  more technically engaged audience than Blog B-1. It builds credibility with
  engineers who will evaluate the Phase 2 feature work.
- **Community C-1 through C-3** convert the research insight — we now know
  exactly who is running DuckLake in production and what their workloads are —
  into a concrete action plan for acquiring early adopters.

All nine deliverables remain zero extension-code changes. The scope is Small.

## What Comes Next

v0.64.0 seeds the demand signals that Phase 2 needs. If the tutorials and demos
produce community interest, the next arc (starting around v0.65.0) delivers the
DuckLake change-feed CDC adapter (INT-3 / F-1), the snapshot-based frontier
(F-3), and the inlined-data trigger adapter (F-5) — turning the documentation
promise into a production-ready feature.
