# 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.