feat: add Langfuse Wasm FDW to the catalog

[distanceqo]

Adds catalog documentation for a community Wasm wrapper for Langfuse, an open source LLM observability platform.

The wrapper exposes traces, observations, token usage, and cost as foreign tables, so LLM spend can be attributed to rows in a local users table in plain SQL:

with llm as (
  select user_id, count(*) as llm_calls, sum(total_cost) as cost_usd
  from langfuse.traces
  where timestamp >= '2026-08-01'::timestamp
  group by user_id
)
select u.email, coalesce(l.llm_calls, 0) as llm_calls, l.cost_usd
from auth.users u
left join llm l on l.user_id = u.id::text
order by l.cost_usd desc nulls last;

It targets the Langfuse Public API rather than the ClickHouse store behind it, which upstream documents as not a stable API contract and which Langfuse Cloud users cannot reach at all.

• Source and releases: https://github.com/distanceqo/langfuse-wasm-fdw
• Built from the postgres-wasm-fdw template, WIT 0.1.0, hence >=0.4.0 in the version table.

Changes

File	Change
docs/catalog/langfuse.md	New page, following the structure of gravatar.md
docs/catalog/index.md	One row in the Official table, one in Community
docs/catalog/wasm/index.md	Card entry
mkdocs.yaml	Nav entry under Wasm

Verification

Installed and queried on a Supabase project against a live Langfuse Cloud project. Everything the docs claim was checked rather than assumed:

• Vault-backed auth, cursor and page-number pagination, lazy page fetching
• limit and equality pushdown; time bounds via fromTimestamp/toTimestamp (and fromStartTime/toStartTime on observations — the column and params differ per endpoint)
• sum(total_cost) agrees at 0.15584 across traces and observations for the same data despite reaching the value through different response fields (totalCost vs calculatedTotalCost), which is why the docs list fallback chains
• A three-way join against auth.users and a local table returns correct per-user attribution

The Limitations section records behaviour found during that testing which may be useful beyond this wrapper:

• now() in a time filter is not pushed down — Postgres reports Wrappers: quals = [] and filters locally after fetching every page. Literal timestamps are pushed.
• v2/observations reads a different store than observations. On a fresh cloud project, rows ingested through both /api/public/ingestion and the OTLP endpoint were readable via observations while v2/observations returned an empty result, though it still validated query parameters.

[burmecia]

hey @distanceqo , thanks for the PR! As this repo is mainly for Supabase maintained FDWs and it is targeting customer on Supabase platform, would you mind move source code into this PR as well?

[distanceqo]

Thanks for taking a look! Source code is now in this PR under wasm-wrappers/fdw/langfuse_fdw/, and the docs are updated to point at a Supabase-hosted release.

Moving into this repo meant a few changes over what I had originally published:

• Retargeted from WIT v1 to v2, which also let me implement import_foreign_schema — so import foreign schema langfuse from server langfuse_server into langfuse now creates both tables.
• Credentials resolve from a Vault secret name via get_vault_secret_by_name, falling back to a secret id, then a plaintext option. The name form saves users having to look a UUID back up.
• Package renamed to supabase:langfuse-fdw, registered in the wasm-wrappers/fdw workspace, edition 2024.

cargo component build --release is clean, as are rustfmt and clippy against wasm32-unknown-unknown.

Two things I'd appreciate your call on:

1. The checksum in docs/catalog/langfuse.md is a placeholder — I can't compute it until a wasm_langfuse_fdw_v0.1.0 release exists. Happy to push the real value once you cut one, or if you'd rather fill it in during release, feel free.

2. v2/observations reads a different store than observations. On a freshly created cloud project, rows ingested through both /api/public/ingestion and the OTLP endpoint were readable via observations while v2/observations returned {"data":[],"meta":{}} — though it still validated query parameters, so the endpoint is live. The wrapper handles both pagination styles and the tables point at observations for now. Worth noting since upstream currently recommends v2.

For reference, this was verified end to end on Supabase against a live Langfuse Cloud project — auth out of Vault, both pagination styles, limit/equality/time pushdown, and a join against auth.users producing correct per-user attribution. sum(total_cost) agrees across traces and observations for the same data despite reaching the value through different response fields, which is what the fallback chains in the docs are for.

[distanceqo]

Fixed the clippy failure — nine format! call sites were using the positional form, which RUSTFLAGS="-D warnings" promotes to an error via uninlined_format_args. My local run had missed it because I wasn't passing that flag.

Verified with the same commands the workflow uses:

cd wasm-wrappers/fdw
cargo component build --release --target wasm32-unknown-unknown -p langfuse_fdw
cargo fmt -p langfuse_fdw && git diff --quiet
RUSTFLAGS="-D warnings" cargo clippy -p langfuse_fdw --tests --no-deps

All clean. The new run needs your approval to start, since I'm a first-time contributor here.

One heads-up in case you hit it: running clippy across the whole wasm-wrappers/fdw workspace on a current toolchain also flags collapsible_if and collapsible_match in several existing wrappers (hubspot, cfd1, infura, orb, clerk). Those are pre-existing and untouched by this PR — just noting it so the output isn't mistaken for something I introduced.

[burmecia]

The checksum in docs/catalog/langfuse.md is a placeholder
No worries, we will handle it during release.

Also, can you add smoke test case for the Wasm FDW? Below are the related files:

• src/fdw/wasm_fdw/tests.rs: smoke test case
• wrappers/dockerfiles/wasm/server.py: mock server and fake test data

Once the test case is in place, you can run cargo component build --release --target wasm32-unknown-unknown and cargo pgrx test --features "pg15 wasm_fdw" to run the smoke test.

[distanceqo]

Smoke test added — wrappers/dockerfiles/wasm/server.py and wrappers/src/fdw/wasm_fdw/tests.rs. Thanks for pointing at those; and good to know the checksum is handled at release time.

I tried to shape the mock so a regression fails rather than quietly passing:

• Pagination is exercised, not assumed. Both endpoints report page/totalPages rather than a cursor, and the server is created with page_size '1' against a two-page traces mock. The assertion expects [trace-1, trace-2], so stopping after the first response fails.
• The pushdown assertion can actually fail. The traces mock returns an empty data for any userId other than user-alice. If the qual were dropped from the URL, the unfiltered rows would come back and assert!(filtered.is_empty()) would break.
• Both field spellings are covered. obs-1 nests usage and cost under usageDetails/costDetails; obs-2 only carries the flat promptTokens / calculatedTotalCost forms. Both have to land in the same columns, so a missing fallback shows up as a NULL that filter_map drops and the length check catches.

I verified the mock endpoints directly with curl (pagination, the userId filter, and that each observation row really only has one of the two shapes). I couldn't run cargo pgrx test locally — no Postgres toolchain on this machine and pgrx init builds it from source — so the Rust side is checked for formatting only. If the smoke test needs an adjustment when it runs in CI, let me know and I'll fix it promptly.