Materialize postgres create
Skill estuary/agent-skills/skills/materialize-postgres-create
Agent skills for setting up and operating Estuary data pipelines through your AI assistant.
npx -y skills add estuary/agent-skills --skill materialize-postgres-createAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Create a PostgreSQL materialization to stream Estuary collections into PostgreSQL tables. Use when setting up PostgreSQL as a destination for captured data. Use when user says "send to Postgres", "materialize to PostgreSQL", "Postgres destination", or "load into Postgres".
SKILL.md
6.9 KB, ~1.6k tokens by cl100k_base, as published. Nobody here has run it
Create PostgreSQL Materialization
Create a PostgreSQL materialization using flowctl to stream data from Estuary collections into PostgreSQL tables.
Applies to: materialize-postgres (all variants: vanilla, RDS, Aurora, Cloud SQL, Supabase, AlloyDB, Neon)
Step 0: Load Connector Documentation
Before proceeding, fetch the official connector docs for prerequisites, config reference, and setup instructions.
Load the docs page: https://docs.estuary.dev/reference/Connectors/materialization-connectors/PostgreSQL/
Use WebFetch to load this page. It covers:
- Prerequisites (user creation, permissions, schema setup)
- Full config property reference
- SSH tunnel configuration
- SSL configuration
- Advanced options (delta updates, hard deletes, sync schedule)
Search Kapa for tribal knowledge (if the Estuary MCP is configured):
Search kapa ai knowledge sources for "materialize postgres common issues"
If Kapa MCP is not configured, the user can set it up: https://docs.estuary.dev/features/mcp-integration/
This skill provides the flowctl workflow and troubleshooting that docs don't cover.
Step 1: Gather Requirements
Before writing any YAML, ask the user:
- Postgres variant? — Vanilla, RDS, Aurora, Cloud SQL, Supabase, AlloyDB
- Network path? — Direct connection (cloud-hosted with IP allowlist), SSH tunnel (private network/on-prem), or ngrok (local dev).
Connection poolers are NOT supported. If the user mentions Supabase, Neon, PgBouncer, or PgCat, warn them immediately:
- The connector uses session-level temporary tables and prepared statements that break with pooled connections.
- Supabase: Must use the Direct connection (
db.xxx.supabase.co:5432), not the pooler (xxx.pooler.supabase.com:6543). - Neon: Must use the non-pooler endpoint — remove
-poolerfrom the hostname.
- Non-default data plane? — Most users use the default. Ask if they need a non-default data plane.
- Target database and schema? — Database name, schema (default:
public) - Source collections? — Which Estuary collections to materialize
- SSL required? — Some cloud providers require SSL connections
- Hard deletes? — Off by default. Without it, deleted rows stay in the destination marked with
_meta/op: 'd'. Enable to physically remove them. - Delta updates? — Off by default. Switches from one-row-per-key (standard merge) to append-only. Use for event logs or history tables.
- Sync schedule? — Controls how often batches are written to the destination (default: 30 minutes,
0sfor real-time). Affects latency and destination compute cost.
Step 2: Find the Correct Connector Version
Always use the latest numbered version tag. Query the connector registry:
flowctl raw get --table connector_tags \
--query 'documentation_url=eq.https://go.estuary.dev/materialize-postgres' \
--query 'select=image_tag,documentation_url' \
--output yaml
Use the returned image_tag — never hardcode a version.
Step 3: Help User Complete Prerequisites
Walk the user through prerequisites from the docs loaded in Step 0:
- Database user — Create a user with write permissions on the target schema
- Schema permissions — USAGE and CREATE on target schema
- Table permissions — SELECT, INSERT, UPDATE, DELETE if materializing to existing tables
- Network access — Firewall rules or SSH tunnel configured
Refer to the docs page for exact SQL commands and cloud-specific instructions.
Step 4: Create the Spec File
Build flow.yaml using the config reference from the docs. Minimal required config:
materializations:
<TENANT>/<PATH>/materialize-postgres:
endpoint:
connector:
image: ghcr.io/estuary/materialize-postgres:<VERSION>
config:
address: "<HOST>:5432"
database: "<DATABASE>"
user: "<USERNAME>"
password: "<PASSWORD>"
schema: "<SCHEMA>"
bindings:
- source: <TENANT>/<collection-path>
resource:
table: "<TABLE_NAME>"
For SSH tunnel or SSL, add the appropriate config block — see docs for full reference.
Step 5: Publish
flowctl catalog publish --source flow.yaml --auto-approve
Step 6: Verify
# Check status
flowctl catalog status <TENANT>/<PATH>/materialize-postgres
# View logs
flowctl logs --task <TENANT>/<PATH>/materialize-postgres --since 5m | jq -c '{ts, message}'
Status progression:
PENDING— Normal for ~30 seconds during shard assignmentBACKFILLING— Initial data sync from collectionOK— Running normally with real-time updates
Troubleshooting
"connection refused" or timeout
Cause: Database not reachable from Estuary cloud
Fix:
- Verify firewall allows Estuary IP addresses (see docs)
- Check security groups (AWS) or firewall rules (GCP)
- Use SSH tunnel for private databases
- For local testing:
ngrok tcp 5432
"password authentication failed"
Cause: Incorrect credentials or user doesn't exist
Fix:
- Verify username and password
- Check user exists:
SELECT * FROM pg_user WHERE usename = '<user>'; - Verify user can connect from external hosts (check
pg_hba.conf)
"permission denied for schema"
Cause: User lacks permissions on target schema
Fix: Grant USAGE and CREATE on the target schema — see docs for SQL.
"relation already exists" or schema conflicts
Cause: Table already exists with incompatible schema
Fix:
- Drop and recreate the table
- Use a different table name
- Ensure collection schema matches existing table
Materialization stuck in PENDING
Wait 30-60 seconds — this is normal during shard assignment. If still stuck:
flowctl logs --task <TENANT>/<PATH>/materialize-postgres --since 5m | jq 'select(.level == "error")'
SSL connection errors
Cause: SSL mode mismatch or certificate issues
Fix:
- Try
sslmode: "require"first - For AWS RDS, SSL is usually required — use
verify-caorverify-full - For self-signed certs, use
requiremode - See docs for full SSL configuration options
SSH tunnel connection failures
Cause: SSH configuration issues
Fix:
- Verify bastion is reachable:
ssh -p 22 user@bastion - Check private key format (must be OpenSSH format)
- Verify bastion can reach database:
nc -zv db-host 5432 - See SSH tunnel troubleshooting docs
Related Skills
connector-disable-enable— Pause/restart existing materializationsconnector-delete-recreate— Nuclear option for stuck materializationsestuary-logs— Deep log analysisestuary-catalog-status— Status checking