Jira to PostgreSQL: How to Move Your Data
Move Jira into PostgreSQL with Airbyte. Why the start date covers only some streams, staying inside the volume guidance, and modelling nested payloads.
Moving Jira into PostgreSQL puts issue data where an application or an internal tool can query it. A team dashboard, a release tracker or a service catalogue that needs to know what is in flight is far simpler to build against a database it already connects to than against Jira's API.
This guide covers the managed path with Airbyte. The Jira connector's catalogue is enormous and mostly describes how your instance is configured rather than what your teams are doing, so stream selection is the design work here, and on a relational destination it also controls whether you stay inside sensible volume.
Jira to PostgreSQL at a glance:
Why move data from Jira to PostgreSQL?
Two situations account for most of these pipelines.
The first is powering an internal tool. Something showing what a team is working on, which services have open incidents, or where review load sits, reading from a database rather than holding Jira credentials and managing its own rate limiting.
The second is joining Jira to data already in that database, such as service ownership or deployment records. If you want multi-year delivery analytics across a large organisation, a warehouse or lakehouse is the better destination, for reasons of volume covered below.
What do you need before you start?
The connector is undemanding to connect and easy to over-configure:
An Atlassian API token. Used with the email address of the account that created it, as basic auth. The token inherits that person's permissions, so it sees exactly the projects and issues they can see. The Jira source documentation covers every field.
A service account to own it. A token created against an individual breaks when they change team, and its visible data changes silently when their permissions change. On a pipeline feeding an application, that second failure shows up as records disappearing from your product.
A decided list of projects. The projects field is optional, and leaving it empty replicates every project the token can see. On a large Atlassian tenancy that is hundreds of projects, which is both more than your application needs and more than a relational destination should hold.
A PostgreSQL user with write access. On the target schema, ideally one dedicated to synced data. If you already run a Postgres destination on an older connector version, read the migration guide before upgrading.
One pleasant note: rate limits are rarely a problem here. The connector is not expected to hit Jira's API limitations under normal usage, so your constraint is what you select rather than how fast you can pull it.
How do you build a Jira to PostgreSQL pipeline in Airbyte?
Step 1: Select only what your application reads
Write down the specific streams and projects your tool needs. Issues, issue comments and a few reference streams usually covers it. Everything else in the catalogue describes screens, schemes and avatars, and on a destination with a volume guideline that material is not just noise, it is cost.
Step 2: Configure the Jira source
Click Sources in the left navigation, then New Source, and select Jira, following adding a source. Supply the API token, your domain in the form yourcompany.atlassian.net, the account email, your project list and a start date.
Step 3: Configure the PostgreSQL destination
Click Destinations, then New Destination, and select Postgres, following adding a destination. From version 3.0.0 the Postgres destination uses Direct Load architecture, writing records straight to final tables with no intermediate raw tables, and adds its own metadata columns alongside your data.
Step 4: Create the connection and expose views
Click Connections, then New connection, and select your streams with a sync mode each. Then build views over the raw tables and point your application at those, so the metadata columns stay invisible and a future schema change can be absorbed in the view rather than breaking whatever reads it.
Run against a couple of projects first and check the resulting tables before extending. Jira instances vary enormously in how they are configured, and what a field contains in one project is not always what it contains in another.
Why does the start date not limit my sync?
This is the configuration detail most likely to surprise you, and it is documented rather than hidden. The start date applies only to a subset of streams: board issues, issue comments, issue properties, issue remote links, issue votes, issue watchers, issue worklogs, issues, pull requests and sprint issues. Every other stream replicates all data regardless.
So a start date of last January bounds your issue activity and hands you the complete contents of every configuration stream you selected alongside it. On a warehouse that is wasteful; on a relational destination with a volume guideline it is the thing most likely to push you past it.
Stream selection therefore has to do the work you might have expected the start date to do, which is exactly why step 1 happens before you open Airbyte. The same logic applies to the projects field: optional does not mean narrow, it means everything.
What do you do about the nested payloads?
Jira issue records nest heavily, carrying status objects, assignee objects, custom field collections and label arrays inside each one. Airbyte preserves that structure rather than guessing at a flattening, which is correct behaviour and genuinely awkward in Postgres.
Postgres has a capable JSON type, and it still gives you less ergonomic support than a warehouse does for working with nested data at scale. So the modelling layer is closer to a requirement than a nicety here: build views extracting the specific fields your application reads, and let it query those.
Custom fields deserve particular attention. Jira exposes them under generated identifiers rather than display names, so without a mapping layer your application is reading fields named after numbers. Syncing the issue fields stream gives you the lookup, and joining it once in a view is the fix.
Frequently asked questions
Why is my Jira sync pulling data older than the start date?
The start date applies to about ten activity streams only. All other streams replicate their full contents regardless of the value you set.
Is PostgreSQL big enough for Jira data?
For a focused set of projects and streams, comfortably. Airbyte recommends relational destinations for roughly 10GB or less, and a large tenancy syncing every stream will exceed that.
Can I limit the sync to certain projects?
Yes. The projects field takes a list, and leaving it empty replicates every project the token's account can see.
Why are my custom fields named after numbers?
Jira exposes custom fields under generated identifiers rather than display names. Sync the issue fields stream and join it in a view to resolve them.
Can I do this without writing code?
The Airbyte setup is entirely UI-driven. You will want SQL views over the nested payloads, which on this destination is closer to a requirement than a nicety.
Get your Jira data into PostgreSQL
Name your projects and select a small set of streams, because the start date will not narrow your sync on its own and the volume guidance leaves less room than a warehouse would. Use a service account, and expose views rather than raw tables so your application reads a stable interface.
Airbyte's connector catalog includes 600+ pre-built connectors, so delivery data can reach an application and a lakehouse at once. For the analytical version, see Jira to Databricks, and for the same source feeding a streaming platform, Jira to Kafka.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.