Google Data Studio (called Looker Studio until April 2026) and Metabase can both start free on BigQuery and Cloud SQL for PostgreSQL. Data Studio is a hosted Google service with no charge for report creators and viewers, and Data Studio Pro costs $9 per user per project per month. Metabase’s open-source edition is free when you run it yourself on Cloud Run or a VM, and Metabase Cloud hosts Metabase for you from $100 a month on the Starter plan. With either tool, BigQuery bills the queries, so cost control comes from BigQuery quotas and from caching.
Google renamed Looker Studio back to Data Studio in April 2026, and Looker Studio Pro is now Data Studio Pro. Data Studio is a separate product from Looker, Google’s enterprise BI platform. Metabase also has a product area Data Studio for curating data, but on this page Data Studio means Google’s product. Prices and plan details were checked on October 7, 2026.
Which one is free? Data Studio, Data Studio Pro and Metabase plans
Data Studio has no charge for report creators and viewers. Data Studio Pro costs $9 per user per project per month, and it adds team workspaces, more delivery options, Gemini AI features and Google Cloud support. Google says the Pro price per user “varies depending on the length of the customer’s subscription.” Google also says: “Users who only need to view reports that are created within a Data Studio Pro environment don’t require a Pro license.” In both tiers, Google notes that reports on BigQuery can incur BigQuery query or storage costs.
Metabase’s open-source edition is free to self-host with unlimited users, and it includes the query builder, the SQL editor, dashboards, subscriptions and guest embeds. Starter is a Metabase Cloud plan at $100 a month with 5 users included, then $6 per extra user per month. Pro costs $575 a month with 10 users included, then $12 per extra user per month, on Metabase Cloud or self-hosted. Enterprise starts at $20,000 a year.
How do you run Metabase on Google Cloud with no server to manage?
Metabase Cloud is the option with no server at all, because Metabase handles setup, backups and upgrades. To self-host on Google Cloud, run the official Docker image on Cloud Run or on a Compute Engine VM, with a Cloud SQL for PostgreSQL instance as Metabase’s application database. Metabase runs background work such as syncs, scans and subscriptions. So on Cloud Run, use instance-based billing, which keeps the CPU allocated between requests, and keep at least one instance running. Metabase’s production guide asks for at least 1 CPU core and 1 GB of RAM. Add 1 CPU and 2 GB of RAM for every 20 people who use Metabase at the same time.
# Open-source Metabase on Cloud Run. Its application database is a Cloud SQL for
# PostgreSQL instance with a private IP (10.20.0.3 here) in the "default" VPC network.
# Follows "Running Metabase on Docker"; flags from Google's "gcloud run deploy" reference.
# The Cloud Run service account needs the Secret Manager Secret Accessor role, and
# --allow-unauthenticated lets people reach Metabase's own sign-in page.
gcloud run deploy metabase \
--image=docker.io/metabase/metabase:v0.64.1 \
--region=us-central1 \
--port=3000 \
--cpu=2 \
--memory=4Gi \
--no-cpu-throttling \
--min=1 \
--network=default \
--subnet=default \
--vpc-egress=private-ranges-only \
--set-env-vars=MB_DB_TYPE=postgres,MB_DB_DBNAME=metabaseappdb,MB_DB_PORT=5432,MB_DB_USER=metabase,MB_DB_HOST=10.20.0.3 \
--set-secrets=MB_DB_PASS=metabase-db-password:1 \
--allow-unauthenticated
Direct VPC egress sends traffic for private addresses into your VPC network, so Metabase reaches the Cloud SQL private IP and the instance needs no public address. Metabase’s production guide suggests the /livez and /readyz endpoints for Cloud Run health checks. The same image also runs with Docker on a Compute Engine VM, as Metabase’s Docker docs show.
How does each tool connect to BigQuery?
Data Studio’s BigQuery connector reads tables, views and custom SQL queries. By default, it queries with the data source owner’s credentials, so viewers don’t need their own BigQuery access, and you can switch to viewer’s credentials or a service account. Whoever runs the queries needs the BigQuery Data Viewer and BigQuery Job User roles.
Metabase connects to BigQuery with a service account JSON key. Metabase’s docs list three roles for that service account: BigQuery Data Viewer, BigQuery Metadata Viewer and BigQuery Job User. You can limit which datasets Metabase syncs with the Only these or All except options.
# A service account for Metabase with the three roles from Metabase's BigQuery docs.
# Follows "Google BigQuery" (Metabase docs) and Google's IAM docs.
PROJECT_ID=my-project
SA="metabase-bigquery@${PROJECT_ID}.iam.gserviceaccount.com"
gcloud iam service-accounts create metabase-bigquery \
--project="$PROJECT_ID" \
--display-name="Metabase BigQuery"
for role in roles/bigquery.dataViewer roles/bigquery.metadataViewer roles/bigquery.jobUser; do
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
--member="serviceAccount:${SA}" \
--role="$role"
done
# Organizations created on or after May 3, 2024 block key creation by default
# (iam.disableServiceAccountKeyCreation); an organization policy admin can exempt the project.
# Upload the key in Metabase under Admin > Databases > Add a database > BigQuery.
gcloud iam service-accounts keys create metabase-bigquery-key.json \
--iam-account="$SA"
How do you control BigQuery cost: maximum bytes billed, quotas and caching?
On-demand BigQuery bills the bytes each query processes, at $6.25 per TiB after the first free TiB each month. BigQuery’s maximum bytes billed setting caps one query job at a time, and a query that would go over it fails without a charge. With on-demand pricing, a custom query quota limits how much data the project’s queries can process each day, and Google describes it as an approximate safeguard. QueryUsagePerUserPerDay applies to every user and service account in the project, including the one Metabase uses, and QueryUsagePerDay caps the whole project.
In Metabase, three settings cut repeat queries:
- Leave Include User ID and query hash in queries turned off. Metabase’s docs note that it prevents BigQuery from caching results, and BigQuery doesn’t charge for queries that it answers from its cache.
- Turn off Re-run queries for simple explorations if you want people to click Run before each change.
- Set a caching policy. The adaptive policy works on every edition, and Pro and Enterprise add duration and schedule policies, plus caching per database, dashboard and question.
Data Studio caches too: a BigQuery data source checks for fresh data every 12 hours by default, and you can set it anywhere from 1 minute to 12 hours. Data Studio can also use BigQuery BI Engine when the project has a BI Engine capacity reservation.
Cloud SQL for PostgreSQL: private IP, authorized networks or an SSH tunnel
Data Studio’s PostgreSQL connector supports public and private IP connections to Cloud SQL. A public IP connection needs Data Studio’s address range, 142.251.74.0/23, in the instance’s authorized networks. The connector returns up to 150,000 rows per query, and Google notes that its queries can time out after three to five minutes.
A self-hosted Metabase on Cloud Run or a VM in the same VPC connects to the Cloud SQL private IP like any other client in that network. From Metabase Cloud, add Metabase Cloud’s IP addresses to the instance’s authorized networks and turn on SSL in the connection. Or keep the instance private and connect through an SSH tunnel to a bastion VM in the VPC.
# Metabase Cloud to a Cloud SQL public IP: allow Metabase Cloud's addresses.
# These are the us-east-1 addresses from "IP addresses to whitelist"; use your region's list.
# This flag replaces the instance's current list, so include every network you still need.
gcloud sql instances patch my-postgres \
--authorized-networks=18.207.81.126/32,3.211.20.157/32,50.17.234.169/32
You don’t need to copy Cloud SQL into BigQuery with Datastream before you chart it in Metabase. Metabase queries Cloud SQL for PostgreSQL directly, and you can add BigQuery as a second database if your events live there.
Row and column security with Google sign-in
Data Studio can filter rows by viewer email for any data source, and Google calls this row-level data security. Viewers must sign in with Google and agree to share their email address. On BigQuery, a custom query can use the @DS_USER_EMAIL parameter, and viewer’s credentials let BigQuery’s own row-level security apply to each viewer.
Metabase supports Google Sign-In on every edition, so people sign in with their Google Workspace accounts, and you can let anyone from your domain create an account. Row and column security, which filters tables by user attributes such as a team or a customer ID, is part of the Pro and Enterprise plans. On those plans, SAML with Google and JWT sign-in sync user attributes from your identity provider. Metabase queries BigQuery with the service account in its connection, so you set the rules for which rows each person sees in Metabase.
Scheduled email delivery and Slack
Data Studio emails a PDF of a report on a schedule. Without Pro, each report can have one schedule, sent at most once a day. Data Studio Pro allows up to 200 schedules per report, sends as often as every hour, and adds delivery to Google Chat and Slack.
Metabase sends dashboard subscriptions by email or Slack on every edition, hourly, daily, weekly or monthly, and one dashboard can have several subscriptions. Subscriptions can attach results as CSV or XLSX files, or the whole dashboard as a PDF, and email can go to people outside Metabase. Pro and Enterprise let you set different filter values for each subscription. On a self-hosted open-source Metabase, email goes through your own SMTP server, and Metabase Cloud manages one for you.
Self-service exploration and embedding
In Data Studio, editors build reports in a drag-and-drop editor, and viewers use filters and date range controls. In Metabase, anyone you give query permissions can build their own questions in the query builder. They pick data, join tables, filter, summarize and chart without SQL, then drill through from the chart. Analysts can use the SQL editor, and both ways to build questions come with every edition.
Data Studio embeds a report in an iframe. Viewers of a privately shared embed must sign in to a Google account, and the Data Studio watermark always shows. Metabase guest embeds work on every edition: your server signs a JWT with locked parameters, such as a customer ID, and viewers don’t need an account. On the open-source and Starter plans, guest embeds show a Powered by Metabase banner. SSO embeds, the React SDK, row and column security and tenants are part of the Pro and Enterprise plans.
When is Data Studio the natural fit?
Data Studio is the natural fit for personal and ad hoc reports across Google’s own data, such as BigQuery, Google Sheets, Google Analytics and Google Ads. It fits best when everyone who reads the reports already has a Google account. It also suits reports and dashboards that you share by link at no cost, with nothing to run.
Metabase fits when people across the team should explore data and build their own questions with the query builder. It also fits when you want Slack delivery, hourly subscriptions or customer embeds with locked parameters on a free edition. And it fits when you want to run BI inside your own Google Cloud project, or let Metabase Cloud run it for you.
Next steps
- Connect Metabase to BigQuery
- Connect Metabase to PostgreSQL
- Run Metabase on Docker
- Set up Google Sign-In
- Cache query results
- Set up an SSH tunnel and find the Metabase Cloud IP addresses
- Set up row and column security
- Send dashboard subscriptions
- Create guest embeds with locked parameters
- Compare Metabase plans