Metabase to PostgreSQL: How to Move Your Data

Moving Metabase into PostgreSQL gives you a queryable inventory of your reporting estate. After a few years, a Metabase instance holds hundreds of questions and dashboards, and nobody can say which are used, which are duplicates, or which quietly broke when a table was renamed.

This guide covers the managed path with Airbyte. Two things shape the build: this carries the catalogue rather than the results, and because the dataset is small and the destination is a general database, you can land it beside the schemas Metabase actually queries.

Metabase to PostgreSQL at a glance:

Why move data from Metabase to PostgreSQL?

Two situations account for most of these pipelines.

The first is governance of the reporting estate. Which dashboards exist, who owns them, how many duplicate questions ask the same thing: these are ordinary database questions once the catalogue is in a database, and effectively unanswerable while it lives behind an interface designed for browsing.

The second is putting the catalogue beside the schemas it refers to, which is the thing this particular destination makes easy. If instead you want to serve the catalogue to an application by key, that is a different access pattern and Metabase to DynamoDB suits it better than a relational database would.

What do you need before you start?

Four things, and the first commits somebody to recurring maintenance:

Metabase credentials, and a decision about which kind. A session token or a username and password, and they fail in different ways. The Metabase source documentation covers both, and the choice is covered below.

Your instance URL, and whether you self-host. Self-hosting lets you configure session duration, which turns a fortnightly chore into an annual one and is the single most useful thing about running your own instance here.

A PostgreSQL database, and a view on where to put it. This dataset is small, so the question is not capacity but placement. Landing it on the same server as the schemas Metabase queries is what makes the interesting analysis possible.

Awareness of the connector version. From version 3.0.0 the destination writes directly without intermediate raw tables and adds metadata columns. A new pipeline gets that by default; an upgrade has a migration to read first.

If your database or Metabase instance restricts traffic by IP, add the Airbyte Cloud IP addresses to the allow list before you begin.

How do you build a Metabase to PostgreSQL pipeline in Airbyte?

Step 1: Choose your credential trade-off deliberately

A session token expires after roughly a fortnight and somebody has to rotate it. A username and password avoids that and generates a new session per authenticated query, which can set off Metabase's security alerting and fill an administrator's inbox with login notifications. Neither is obviously right, and if you self-host, extending the session duration sidesteps the choice entirely. Decide now rather than discovering it through whichever failure arrives first.

Step 2: Configure the Metabase source

Click Sources in the left navigation, then New Source, and select Metabase, following adding a source. Supply your instance URL and credentials. Expect definitions rather than data: this carries the questions, dashboards and collections themselves, not the rows those questions return when somebody runs them.

Step 3: Configure the PostgreSQL destination

Click Destinations, then New Destination, and select PostgreSQL, following adding a destination. Supply the host, port, database and credentials. Give it its own schema, ideally on a server that already holds the data Metabase reports on, since that adjacency is the point of choosing this destination.

Step 4: Create the connection and schedule it gently

Click Connections, then New connection, select your streams and a sync mode. Daily is generous for a catalogue that changes when somebody builds a dashboard. If you are using password authentication, a gentler schedule also means fewer sessions and fewer security notifications.

Put views over the tables so the metadata columns the destination adds stay out of everybody's queries.

What does a catalogue actually let you answer?

Questions about the estate rather than about the business. What exists, who created it, when it was last modified, how collections are organised and how many questions ask variations of the same thing. None of that is what people usually mean by reporting data, and all of it is hard to establish from inside Metabase once the instance is large.

It is worth being explicit about this early, because somebody asking for Metabase data in the warehouse usually means the numbers their dashboards display. Those live in whatever database Metabase queries, and this pipeline does not fetch them. Handing over a catalogue when somebody expected results is a disappointing end to otherwise correct work.

Taken for what it is, the catalogue supports a genuinely useful clear-out. Dashboards nobody has opened, questions duplicated across collections, content owned by people who left: these accumulate in every instance and the only way to see the pattern is to query it. That is a governance exercise most organisations put off indefinitely because the data was never available.

Why land this beside the databases Metabase queries?

Because it lets you close a loop that is otherwise open. Metabase questions reference tables and columns in your databases, and those databases change without Metabase being told. Tables get renamed, columns get dropped, and the question keeps existing in the interface while quietly failing or returning something wrong for whoever runs it next.

With the catalogue in the same PostgreSQL server as the schemas it refers to, you can compare the two. Check the table names a question references against the system catalog of the database it queries, and anything referring to something that no longer exists is a broken question you can find deliberately rather than waiting for a complaint. This is only comfortable because the dataset is small and both sides are in one place.

Two practical notes. Question definitions vary in shape depending on whether somebody wrote SQL or built a query visually, so treat this as a heuristic that finds most problems rather than a complete verifier. And build it as a view alongside the ones hiding the pipeline's metadata columns, so whoever inherits this finds the useful queries already written rather than having to invent them.

Frequently asked questions

Does this give me the data behind my dashboards?

No. It carries the catalogue, meaning the definitions of questions, dashboards and collections. The rows those questions return stay in whichever database Metabase queries.

Why did the pipeline stop after two weeks?

The session token expired, since those last around fourteen days. Rotate it, or self-host and extend the session duration so it becomes an annual task.

Our administrator is getting login alerts.

Password authentication generates a new session per authenticated query, which security alerting notices. Either warn the administrator in advance or use a session token instead.

Can I find questions that reference dropped tables?

Largely, if the catalogue sits beside the database being queried. Compare referenced table names against the system catalog, and treat it as a heuristic since question definitions vary in shape.

Can I do this without writing code?

The pipeline, yes, and the setup is short. The views that hide metadata columns and check for broken references are SQL, and they are what makes this dataset worth having.

Get your Metabase data into PostgreSQL

Decide the credential trade-off before it decides for you: a token expiring every fortnight, or a password generating sessions that worry your administrator, or a longer session duration if you self-host. Be clear with everybody that this is the catalogue rather than the results. Then land it beside the databases Metabase queries, because comparing question definitions against the schemas they depend on is the thing this destination makes possible and the reason to prefer it.

Airbyte's connector catalog includes 600+ pre-built connectors, so a reporting estate can be governed like any other system. For the same source into a warehouse, see Metabase to BigQuery, and for another catalogue source into the same destination, Dremio to PostgreSQL.

Start syncing now →