v1.2.0

New capability — Postgres/Supabase sources in named connections are now runnable (#14)

Previously, a platform: postgres/supabase source under connections: compiled but failed at run time (no credentials on the foreign server). Now the FDW bridge emits a CREATE USER MAPPING, and run injects the source user/password from .df-credentials.json's connections map at execution time.

• Compile emits non-secret placeholders (${SA_CONN:<conn>:user|password}) — secrets never enter the compiled graph or --dry-run/--json output.
• Run substitutes them at the execution choke point, with fail-fast validation if a connection's creds are missing.
• BigQuery sources (non-secret saKeyId path) are unchanged.
• Verified with core unit tests, a CLI substitution unit test, and a live-Postgres integration test (loopback postgres_fdw reading through the foreign table).

For Postgres/Supabase sources: put non-secret host/port/database in workflow_settings.yaml's connection, and the secret user/password under connections.<name> in .df-credentials.json.

v1.1.2

Fix

• introspect + run can now share one .df-credentials.json. Source-connection
  credentials for sqlanvil introspect go under a connections: { <name>: {...} } map,
  alongside the flat write-warehouse credentials. run validates the warehouse creds and
  ignores connections; introspect reads from it. Previously the two were mutually
  exclusive (the strict warehouse-creds validator rejected the per-connection keys
  introspect required), so the named-connections introspect workflow couldn't be used in
  a real project. Backward-compatible: a flat file with no connections key is unchanged.

Docs

• Named-connections docs scoped to BigQuery sources (the supported path). Postgres/Supabase
  sources compile but aren't yet runnable (the postgres_fdw user mapping isn't emitted) —
  tracked for a future release.

v1.1.1 — fix: named connections were dropped in the packaged 1.1.0

Hotfix for 1.1.0. The 1.1.0 packaged `@sqlanvil/core` silently dropped the `connections` map from `workflow_settings.yaml` when run through the CLI, so connection-tagged declarations failed with Unknown connection "…". The bug was a protobuf-map + minification interaction ({...projectConfig} spread dropped map fields once the core bundle was minified); it wasn't caught because the unit tests run the unminified library, never the packaged bundle. Fixed by setting connections explicitly in the projectConfig merge (as vars already was).

If you're using the named connections / connection: on declarations feature from 1.1.0, upgrade to 1.1.1.

npm install -g @sqlanvil/cli   # 1.1.1

Verified end-to-end: the supabase_bigquery_mailing_list example (now refactored to the named-connections model) compiles cleanly through the packaged bundle.

v1.1.0 — Named connections + schema introspection

Read foreign sources declaratively, without hand-writing FDW boilerplate. Builds on the cross-warehouse Foreign Data Wrappers from 1.0.3.

Highlights

• Named connections. Define connections: in workflow_settings.yaml (non-secret platform/project/dataset/saKeyId/host defs; secrets stay in .df-credentials.json, keyed by connection name). warehouse: may name a connection. Tag a declaration with connection: and SQLAnvil auto-generates the read-only FDW bridge (BigQuery or Postgres source) — the table becomes ref()-able like any source. connection: is valid only on declarations (tables/views always build into your one read/write warehouse).
• sqlanvil introspect <connection> <schema.table>. Reads a source table's columns + comments, maps source types to your warehouse dialect (BigQuery → Postgres; Postgres → Postgres), and writes a ready-to-use declaration .sqlx with columnTypes filled in (--output <file> or stdout). Dev-time only — compile/run never touch the network for schema.
• sqlanvil init now defaults to --warehouse supabase (was bigquery), fitting the Postgres/Supabase-first focus. Pass --warehouse postgres|bigquery to override.

Install

npm install -g @sqlanvil/cli   # 1.1.0

Docs

• Foreign Data Wrappers (named connections + introspect): https://sqlanvil.com/docs/guides/foreign-wrappers/

---

SQLAnvil is not affiliated with or endorsed by Google. The Dataform name and related marks are trademarks of Google LLC; see NOTICE for attribution.

v1.0.3 — cross-warehouse Foreign Data Wrappers

Adds first-class Foreign Data Wrapper support to the wrapper() action, enabling live cross-warehouse queries — e.g. joining Supabase operational data with BigQuery in place.

Highlights

• wrapper() provider presets — wrapper({ provider: "bigquery", server, serverOptions, credential, foreignTables }) emits a complete, correct BigQuery FDW bridge: enables the wrappers extension, registers the FDW (idempotent), and creates the server. Generic FDW is still reachable on any Postgres via explicit wrapper/handler/validator.
• Ref-able foreign tables — each foreignTables[] entry becomes a ref()-able table, so downstream models consume external data like any other source. Foreign tables depend on the server setup automatically.
• Credential model — references a pre-existing Supabase Vault secret by id (saKeyId); the service-account key JSON is never handled by SQLAnvil. Postgres-first design — only the credential path is Supabase-specific.
• New example — examples/supabase_bigquery_mailing_list: builds a proximity mailing list of recent purchasers near a target ZIP, joining Supabase orders with Google's bigquery-public-data ZIP geo data via the FDW and PostGIS distance math.

Install

npm install -g @sqlanvil/cli   # 1.0.3

---

SQLAnvil is not affiliated with or endorsed by Google. The Dataform name and related marks are trademarks of Google LLC; see NOTICE for attribution.

v1.0.2 — first public SQLAnvil release

SQLAnvil is an open-source SQL workflow tool for BigQuery, PostgreSQL, and Supabase — a fork of Dataform OSS (Apache-2.0) extended with first-class Postgres/Supabase support (upstream Dataform OSS dropped Postgres after Google's acquisition).

This is the first public GitHub release of the SQLAnvil 1.x line. Install:

npm install -g @sqlanvil/cli
sqlanvil init my-project --warehouse postgres   # or: supabase | bigquery

Highlights of the 1.0.x line

• Three first-class warehouses — BigQuery, PostgreSQL, and Supabase. Postgres/Supabase generate idiomatic Postgres DDL/DML (native partitioning, INSERT … ON CONFLICT upserts, btree/gin/gist/brin indexes, materialized views), not translated BigQuery SQL.
• Supabase-native action types — RLS policies, Realtime publications, and pgvector indexes, with RLS enforcement verified end-to-end against live Postgres.
• Flat config + gitignored credentials — workflow_settings.yaml holds a flat warehouse: string and non-secret defaults; the connection (with secrets) lives in a gitignored .df-credentials.json. Unknown warehouse: values are rejected instead of silently defaulting to BigQuery.
• Fail-fast connection probe — the Postgres/Supabase adapters verify the connection on create, so misconfigured hosts fail immediately with a clear error instead of hanging or tripping Supabase's pooler lockout.
• Warehouse-aware init — sqlanvil init --warehouse {postgres,supabase,bigquery} scaffolds the right workflow_settings.yaml + .df-credentials.json template.
• Decoupled versioning — SQLAnvil has its own SemVer line; sqlanvil --version also reports the upstream Dataform core it's synced to.

What's new in 1.0.2

• npm packages (@sqlanvil/cli, @sqlanvil/core) now ship README.md, LICENSE, and NOTICE in the published tarball, so the npm package pages render the README and the Apache-2.0 license file is included in the artifact.

Docs

• Guides and reference: https://sqlanvil.com
• Supabase quickstart template: https://github.com/SQLAnvil/supabase-sqlanvil-starter

---

SQLAnvil is not affiliated with or endorsed by Google. The Dataform name and related marks are trademarks of Google LLC; see NOTICE for attribution.