Skip to main content

How to Connect PostgreSQL as a Data Source in Alta (Connectors)

Connect a Postgres database through the Connectors library so Alta syncs the tables you choose to power metrics, dashboards, and Luna.

Written by Katie Supporté

PostgreSQL often backs your product or internal apps, holding operational data you can't get anywhere else. Connecting it as a data source through the Connectors library lets Alta sync the tables you choose straight from your database, where they become training data for Alta and a foundation for your metrics, dashboards, and Luna analysis. Postgres connects with database credentials.

Who this is for: Engineering and data teams who want tables from a Postgres database measured and queried in Alta.


Before you start

  • Have your connection details ready: host, port, database, schema, and a username and password with read access.

  • Make sure the database is reachable from Alta (public endpoint or allow-listed IPs / SSH tunnel as your setup requires).

  • Use a dedicated read-only user scoped to the schema you want to expose.

  • Connect a source only once per workspace. If Postgres already shows Connected, edit the existing connection.

Connect PostgreSQL

  1. Open Connectors from the sidebar.

  2. Find Postgres via the Data tab or the Search data sources box.

  3. Click the Postgres card to open the Create connector screen.

  4. Fill in the connection fields shown (host, port, database, schema, username, password), then click Create.

  5. Alta runs a connect test. If it fails you'll see The connect test has failed with the database error — fix the field and retry.

  6. The card then shows Connected and Data is syncing until the first sync finishes.

Choose which tables sync

  1. Open the connection. The Postgres tables section lists the tables in the schema you connected.

  2. Use the Synced toggle to choose which tables Alta pulls in.

  3. Turn off Show only synced tables to browse everything available.

What gets synced — your own tables

A database has no fixed schema for this purpose — you decide which of your own tables sync, and the columns are whatever your app defines. A good rule of thumb:

  • Core entity tables — users/accounts, orders/transactions, subscriptions — the records you report on.

  • An amount and a date column on the tables you want to trend or sum.

  • Lookup tables (plans, statuses, regions) that give your IDs readable labels.

What you can ask this data

The questions follow your tables. Once synced, build metrics and dashboards or ask Luna / Ask AI, for example:

  • "Sum [your amount column] by month from [your table]."

  • "How many new [users/orders] per week?"

  • "Which [accounts/products] are most active?"

  • "Compare product usage in my app database to CRM pipeline to see which accounts are most engaged."

Example use cases

  • Product/operational metrics. Signups, orders, or usage straight from the app DB — no export needed.

  • Usage-to-revenue. Join app activity to CRM or billing data to connect engagement with revenue.

  • Operational dashboards. Live counts and trends the whole team can read or ask Luna about.

Keep it in sync

  • Sync status shows Last sync (Succeeded/Failed) and the Sync frequency.

  • Click Sync now to refresh immediately; it's disabled while a sync runs.

  • Use the overflow menu () to Disable, Enable, or Delete.

Tips and common pitfalls

  • Network access is the usual blocker. Firewalls, security groups, or a missing SSH tunnel cause most failed connect tests.

  • Use a read-only user scoped to the schema you want to expose.

  • Big tables sync slowly. Pick the tables you actually report on rather than the whole schema.

  • Deleting is permanent. Disable instead to pause.


Related

Did this answer your question?