Integration · Looker Studio

PostgreSQL to Looker Studio

There is no export to build. Looker Studio has a native PostgreSQL connector — the decision that actually matters is which database you point it at.

There is no export step

Looker Studio ships with a built-in PostgreSQL connector. You give it a host, port, database, user and password, and it reads your tables directly — no CSV, no Google Sheets in the middle, no scheduled job to babysit. You can also hand it a custom SQL query instead of a table, so the joins and aggregation happen once in the data source rather than being rebuilt in every chart. If you came here looking for how to export PostgreSQL to Looker Studio, that is the answer, and it is free.

Which turns the interesting question into a different one. Looker Studio connects from Google's servers, not from your laptop, so whichever database you name has to be reachable from the internet with Google's IP ranges allowed through. Every chart refresh, from every viewer you shared the report with, becomes a query against that database on a schedule you don't control. Doing that to a production database is the part of this that goes wrong — not the connecting, the choosing.

Three ways people do this

They are genuinely different trade-offs, and the right one depends on what that PostgreSQL database is.

Point Looker Studio straight at your PostgreSQL

The native connector, no extra moving parts. The correct answer when the database is already a reporting replica or a warehouse.

  • Free, and nothing to maintain between the two
  • Always current — no pipeline to fall behind
  • Custom SQL supported, so heavy joins live in the data source
  • The database must be reachable from Google's servers, with their IP ranges allowed
  • Report traffic lands on that database, at whatever rate viewers refresh
  • Anyone who can edit the data source is one step from the credentials

Export to CSV or Google Sheets

The instinct behind most searches for this, and the option that ages worst.

  • Nothing to open up to the internet
  • Fine for a genuine one-off, like a board slide
  • Stale the moment it is written, and nothing tells you it went stale
  • Somebody has to remember to redo it
  • Sheets tops out around 10 million cells — roughly 500k rows across 20 columns

Point it at an isolated copy

Same native connector, aimed somewhere expendable. This is the one BeQuery exists for.

  • Production is never the thing Google is allowed to reach
  • A slow report cannot slow down checkout
  • Credentials you can hand out and revoke without touching the real database
  • Something has to keep the copy in sync — that part is the actual work
  • The copy is as fresh as its last sync, not to the second

When you don't need BeQuery for this

If your PostgreSQL is already a read replica, a staging copy or a warehouse you are happy to expose to Google, connect Looker Studio to it directly and you are finished. That path costs nothing and we would rather you took it than paid us for something you don't need. BeQuery earns its place in two cases: when the only database you could expose is the one your business actually runs on, and when your data isn't in PostgreSQL at all. PrestaShop, WooCommerce and Magento live in MySQL — Looker Studio can read MySQL too, so the temptation is to aim it at the shop, which means a dashboard link you shared with a colleague is now issuing queries against the database taking orders.

Why the pairing works

  • The native PostgreSQL connector reads the clone directly — no export, no scheduled job
  • Google's IP ranges reach a copy, never the database taking orders
  • Read-only credentials you can share with a contractor and revoke on their own

Connect it

1

Get a PostgreSQL copy

Connect your MySQL store — PrestaShop, WooCommerce, Magento — and BeQuery clones it into an isolated PostgreSQL schema. Already on PostgreSQL? Skip to step three and point Looker Studio at it.

2

Enable external access

Turn on external connections in Settings and copy the read-only host, database, user and password. They are scoped to your team's schema and to SELECT.

3

Add the data source

In Looker Studio: Add data → PostgreSQL → paste the credentials. Pick a table, or paste a custom query if your report needs a join.

4

Share the report, not the database

Anyone you share with reads through the data source. The clone absorbs the traffic; production never sees it.

Common questions

Does Looker Studio have a PostgreSQL connector?

Yes — it's built in and free, alongside the MySQL and SQL Server ones. You add it under Add data → PostgreSQL and give it a host, port, database and credentials. There is no export step and no third-party connector to install.

Do I have to expose my database to the internet?

For any database connector, yes in practice: Looker Studio connects from Google's servers, so the host has to be reachable and Google's IP ranges have to be allowed through your firewall. That is exactly why pointing it at a production database is a bad trade, and why aiming it at a disposable copy is the safer shape of the same setup.

Can I use a custom SQL query instead of a table?

Yes. A PostgreSQL data source accepts a custom query, which is usually the better choice: write the join and the aggregation once there, rather than repeating it across six charts that can drift apart.

How fresh is the data in the report?

Two layers. Your BeQuery sync decides how current the clone is — hourly on Cloud, down to near real-time on Enterprise. Looker Studio then caches results and refreshes on the interval set in the data source, so a report is never fresher than the slower of the two.

My store is MySQL, not PostgreSQL — does this still apply?

It does, and it's the more common case. Looker Studio can read MySQL directly, but that means aiming a shared report at the database serving your shop, and PrestaShop and Magento schemas are hostile to report over anyway — prefixes, EAV, product names nowhere near the sales tables. BeQuery clones MySQL into PostgreSQL so the report reads a copy with a schema you can actually chart.

Which plan do I need for external connections?

External PostgreSQL connections, the ones Looker Studio needs, are on the Cloud and Enterprise plans — see pricing. The clone itself and the in-app analytics work on every plan.