PostgreSQL
Register your own PostgreSQL database as a DualEntry export destination. DualEntry validates the connection and holds the credentials so your export jobs can write to it.
Overview
You already run the database. Your analysts query it, your dashboards point at it, and finance data needs to land there in a shape your own tooling understands. PostgreSQL in DualEntry is not a general-ledger sync like Stripe or Brex. It is an export destination: you hand DualEntry the connection details, and DualEntry makes them available to the export infrastructure that writes into your database.
The mechanism is deliberately narrow. You supply a host, port, database name, username, password, and an optional SSL mode. DualEntry validates that payload against a fixed credential schema, then opens a connection to PostgreSQL with a ten-second connect timeout and closes it again. A clean open and close counts as validation. On success the destination moves from Pending through Testing to Validated, the linked integration shows as Connected, and the full credential payload is written to AWS Secrets Manager.
Flow runs one way: out of DualEntry and into your database. Downstream AWS-based export jobs, typically AWS Glue pipelines configured for your organization, read the credentials from Secrets Manager and perform the actual writes. DualEntry does not read from your PostgreSQL instance, and nothing in your database flows back into the ledger.
So be precise about what connecting does. It registers and tests an export destination. It does not start a sync. Table layout, job cadence, and the SQL for specific datasets are owned by your deployment's export configuration, not by this integration. One active PostgreSQL export integration is allowed per organization.
Connection metadata
Only the non-sensitive fields from your credential payload are stored in DualEntry's own database: engine, host, port, and database name. These identify where exports are pointed.
Credential payload
The full payload, including username and password, is written to AWS Secrets Manager under a secret name keyed to your organization and the destination identifier. It is never returned by DualEntry's APIs after creation.
Destination and integration status
The destination's status (Pending, Testing, Validated, or Failed) and the linked integration's state (Connected, Error, or Disconnected) are recorded, along with the error message from a failed validation.
Connection attempt details
The connection log records the egress IP DualEntry attempted from, which your platform team can use to confirm firewall, security group, or network ACL rules after a failed attempt.
Exported datasets
What actually gets written into your database is determined by your deployment's export configuration rather than by this integration. The documentation for this destination does not enumerate specific accounting record types.
Data synced
The integration syncs the following data types:
- The credential payload requires type set to the literal "database", engine set to postgres, a non-empty host, a TCP port in the range 1-65535, a database name, a username, and a password.
- PostgreSQL's default port is 5432, and the same credential schema also covers redshift, mysql, mariadb, and sqlserver, with dispatch handled by the engine field.
- The optional ssl_mode field accepts disable, require, verify-ca, or verify-full, and defaults to require.
- The schema does not collect a PostgreSQL schema name, so downstream export jobs use the default search path for the given database and user, or pin a schema in their own configuration.
- One active PostgreSQL export integration is allowed per organization, enforced at the API level with a 400 "integration already exists" error on create.
- Saving a destination returns immediately with a status of Pending, and credential validation runs in the background rather than inline.
- During validation DualEntry opens a connection to PostgreSQL using the supplied credentials with a ten-second connect timeout, then closes it; a clean open and close counts as validation.
- On success the destination moves from Pending to Testing to Validated, the linked integration shows as Connected, and the credentials are written to AWS Secrets Manager.
- On failure the destination shows Failed with an error message and the linked integration is set to Error.
- A failed row is retained for audit and does not retry automatically, so retrying means fixing the underlying cause and creating a new destination.
- DualEntry does not automatically sync data into PostgreSQL as part of this flow; the connect flow registers and tests credentials only.
- Downstream AWS-based export jobs, typically AWS Glue pipelines configured for your organization, read the credentials from AWS Secrets Manager and write data into your database.
- Table layout, job cadence, and the SQL for specific datasets are owned by your deployment's export configuration rather than by this integration.
- Data moves out of DualEntry and into your database; DualEntry does not read from your PostgreSQL instance as part of this integration.
- Amazon RDS for PostgreSQL and Aurora PostgreSQL work with engine=postgres, while Amazon Redshift uses engine=redshift on the same schema with an identical validation path.
- DualEntry stores only engine, host, port, and database in its relational database, held as the non-sensitive metadata on the export-secret row.
- The username and password live exclusively in AWS Secrets Manager and are never returned by DualEntry's APIs after creation.
- Secrets are stored under a name keyed to your organization and the destination's identifier.
- There is no in-place credential edit, so any rotation or password reset has to be handled as a full re-create of the destination.
- TLS should be configured on the database; DualEntry defaults to sslmode=require, and production destinations should use require or stricter.
- Disconnecting archives the export-secret row, marks the integration as Disconnected, and schedules deletion of the AWS Secrets Manager entry subject to AWS's standard recovery window.
- Disconnect is blocked while an AWS Glue export job tied to the integration is in a Running state, and the call returns an error naming the active job ID.
- Reusing the same secret name within the AWS recovery window will collide.
- Connection refused or timeout errors usually mean the instance is unreachable from DualEntry's worker network, or that the ten-second connect timeout is too aggressive for a cold or scaled-to-zero instance.
- The connection log records the egress IP DualEntry attempted from, so your platform team can confirm security group, firewall, or network ACL rules during failed attempts.
Key Features
- An export destination, not a sync
Connecting registers and validates PostgreSQL connectivity. DualEntry does not automatically sync data into your database as part of this flow. - Validated in the background
Saving returns immediately with the destination in Pending status, then a background job opens and closes a real connection using your credentials. A clean open and close counts as validation. - Status you can watch
The destination progresses from Pending to Testing to Validated, or lands on Failed with an error message and sets the linked integration to Error. - TLS to your standard
DualEntry defaults to sslmode=require and supports disable, require, verify-ca, and verify-full. Production destinations should use require or stricter. - Managed PostgreSQL and Redshift
Amazon RDS for PostgreSQL and Aurora PostgreSQL work with engine=postgres. Amazon Redshift uses engine=redshift on the same credential schema and an identical validation path. - One destination per organization
A single active PostgreSQL export integration is allowed per organization, enforced at the API level. The same rule applies to Snowflake, Qlik, and Power BI. - Disconnect that respects running jobs
Disconnecting archives the export-secret row and schedules deletion of the Secrets Manager entry, but is blocked while an AWS Glue export job tied to the integration is still running. - Credentials held outside the product database
DualEntry stores only engine, host, port, and database name in its own database. Username and password live exclusively in AWS Secrets Manager and are never returned by DualEntry's APIs after creation.
FAQ
No. This integration is an export destination, not a general-ledger sync. Data moves out of DualEntry and into your database, and DualEntry does not read from your PostgreSQL instance as part of this flow.
Downstream AWS-based export infrastructure does, typically AWS Glue pipelines configured for your organization. Those jobs read your PostgreSQL credentials from AWS Secrets Manager and write data into your database.
The connect flow in DualEntry registers and tests the credentials so that infrastructure has something to read. It does not move data itself.
In AWS Secrets Manager, under a secret name keyed to your organization and the destination's identifier. The username and password never land in DualEntry's relational database and are never returned by DualEntry's APIs after creation.
DualEntry stores only the non-sensitive metadata: engine, host, port, and database name. Because there is no in-place credential edit, treat any rotation or reset as a full re-create of the destination.
Not by this integration. Table layout, job cadence, and the SQL for specific datasets are owned by your deployment's export configuration. Connecting PostgreSQL here registers and validates a destination; it does not set a schedule or start a sync.
The destination shows Failed with an error message and the linked integration is set to Error. Common causes are a wrong host, port, username or password, a role missing CONNECT on the database, an unreachable instance, or an ssl_mode stricter than the server's certificate supports.
Failed rows are kept for audit but do not retry automatically. Fix the underlying cause and create a new destination.
Yes. Amazon RDS for PostgreSQL and Aurora PostgreSQL both work with engine=postgres. Amazon Redshift uses engine=redshift on the same credential schema, and the validation path is identical, so the same operational notes apply.
.avif)