Skip to main content

Documentation Index

Fetch the complete documentation index at: https://parabola.io/docs/llms.txt

Use this file to discover all available pages before exploring further.

PostgreSQL is an open-source relational database used for transactional applications, analytics, and reporting workloads from startups through enterprise. Connecting PostgreSQL to Parabola lets analysts and ops teams query Postgres on a schedule, blend the results with other systems, and write cleaned data back into Postgres tables, without writing a custom ETL pipeline or waiting on engineering.

Pull from PostgreSQL

The Pull from PostgreSQL step connects to a PostgreSQL database and brings query results into your flow. Pick a table for the default select * pull, or write a custom SQL query to filter, join, and aggregate before the data reaches Parabola.

How to authenticate

1
Add a Pull from PostgreSQL step to your flow and double-click to open it.
2
Click Authorize and enter your connection details:
  • Hostname
  • Username
  • Password (optional)
  • Database
  • Port (optional, defaults to 5432)
Pull from PostgreSQL authorization modal showing hostname, username, password, database, and port fields
If your database doesn’t require a value (a password, for example), leave that field blank. If you’re not sure where to find these values, check your connection string or ask your database administrator.
3
Pick a table from the dropdown. By default the step runs select * against that table.

Configure your settings

To narrow the result set, write SQL in the Query (optional) field. A targeted query keeps the pull fast and avoids dragging entire historical tables into the flow. Two AI buttons live next to the query field:
  • Help write query — describe the data you want in plain language (for example, “Show me the last 30 days of shipped orders”) and AI drafts the SQL for you.
  • Optimize query — paste an existing query to fix syntax errors, improve performance, or refine the logic.
Both buttons open the AI chat where you can keep iterating until the query is right.

Send to PostgreSQL

The Send to PostgreSQL step inserts, updates, or upserts rows in a remote Postgres database, useful for syncing reconciled data back into operational tables or pushing transformed records to a reporting database.

How to authenticate

1
Add a Send to PostgreSQL step to your flow and double-click to open it.
2
Click Authorize and enter your connection details. The step defaults to port 5432 if no port is provided.
Send to PostgreSQL authorization modal showing hostname, username, password, database, and port fields

Configure your settings

Once connected, pick the destination table from the dropdown. Maximum Connections — defaults to 20. Parabola splits your rows across this many concurrent connections to write faster. Every database has a maximum number of connections it accepts, so set Parabola’s value to no more than 50–60% of that ceiling. Above the ceiling and the step errors out; at the ceiling and nothing else can connect to the database while the flow runs. Talk to whoever owns the database if you’re not sure. Operations — pick how rows should land:
  • Insert — adds new rows. Make sure duplicates are okay; Parabola won’t dedupe for you.
  • Upsert — updates existing rows where a primary key matches, inserts the rest. Requires a unique identifier column on the database table and a matching column in your Parabola data.
  • Update — only updates existing rows. Same primary-key requirement as upsert. Rows that don’t match are skipped.
After picking the operation, map your Parabola columns to the columns in your Postgres table. Unmapped columns can stay blank.

How errors are handled

Send to PostgreSQL processes rows top to bottom. Unlike most Parabola export steps, it doesn’t halt on a row failure. It logs the error, skips the row, and keeps going. If every row succeeds the step finishes in a normal state; if any row was skipped due to errors the step finishes in a failure state with the bad rows logged.

Available data

The PostgreSQL integration works against any database the connection has access to:
  • Pull: any table or view in the connected database, plus arbitrary SQL queries (joins, CTEs, window functions, subqueries).
  • Send: any table the connection has insert/update privileges on.
  • AI query helpers for drafting and optimizing SQL inside the step.

Common use cases

  • Build reports that combine app data with the rest of the business: Pull from Postgres, join with Shopify orders, Klaviyo engagement, and Stripe payouts, and drop the result in Google Drive or Smartsheet on a schedule.
  • Push reconciled data back into Postgres: Clean and join data from across the business in Parabola, then write the result back to a Postgres reporting table for BI tools to consume.
  • Move Postgres data into a warehouse: Pull from Postgres and push into Snowflake, BigQuery, or Redshift so analysts can query production data alongside the rest of the stack.
  • Sync product or customer data to marketing tools: Pull users from Postgres and push them into Mailchimp, HubSpot, or Klaviyo so lifecycle campaigns stay current without engineering work.
  • Trigger ops alerts on database conditions: Run a query on a schedule, then send a Slack alert when a count, sum, or status flag crosses a threshold.
  • Reconcile internal Postgres data with vendor systems: Compare Postgres records with data from NetSuite, QuickBooks Online, or Fulfil to catch sync gaps before close.

Tips for using Parabola with PostgreSQL

  • Filter in SQL, not in Parabola. Add where clauses, date ranges, and column selection to your query so only the rows you need cross the wire. Faster runs and cleaner downstream logic.
  • Use limit while building. Add limit 100 while you’re wiring up the flow. Remove it before scheduling so the production run pulls everything.
  • Allow-list Parabola’s IPs. If your Postgres server restricts inbound traffic (RDS security groups, firewalls, pg_hba rules), add Parabola’s IP ranges so the connection isn’t blocked.
  • Cast types before sending. Send to PostgreSQL writes everything as strings. Make sure target columns accept strings, or cast on the database side. Null values arrive as empty strings, not true NULL.
  • Match column names exactly. Use a Rename columns step before sending so Parabola column names line up with the Postgres table. Mismatches cause skipped rows.
  • Use schemas in your queries. If your database uses non-public schemas, fully qualify table names (analytics.orders) in your SQL to avoid ambiguous lookups.
  • Match cadence to use case. Every 15 minutes for ops dashboards, daily for finance reports, weekly for cohort analysis.

FAQ

Can Parabola write true NULL values to PostgreSQL?

No. Send to PostgreSQL writes empty strings instead of NULL. If your column needs true NULL, write the row, then run an UPDATE ... SET column = NULL WHERE column = '' on the database side, or handle the conversion with a trigger on the destination table.

Does Parabola support SSL connections to Postgres?

Connection encryption depends on the server’s configuration. For databases that require SSL (most managed Postgres services do), use the connection-string options exposed in the auth modal. If your setup needs a tunnel or specific cert handling, contact help@parabola.io.

How do I send only changed rows to Postgres?

Use the Upsert operation with a primary key, or filter rows in Parabola to only the changed records before the Send to PostgreSQL step. Many teams pull a snapshot of the destination, diff it against the new data, and only send rows that differ.

Why does the step skip some rows instead of failing?

Send to PostgreSQL is designed not to halt on a single bad row. It logs the error, skips the row, and continues. The step ends in a failure state if any row was skipped, with the errors visible in the run log so you can fix and re-run.

Can I run multiple statements in the Pull query?

The Pull from PostgreSQL step expects a single query. Wrap multi-statement logic in a view or function, then pull from the view, or chain multiple Pull steps and join in Parabola.
With PostgreSQL and Parabola connected, the queries your team runs by hand every week, the exports pasted into spreadsheets, and the manual writebacks into operational tables all become flows that run on a schedule.
Last modified on May 18, 2026