Both show up across QueryFlow's connectors. Neither is universally better; the right one depends on whether a person or a process owns the connection.
No credit card. 14 days. Cancel in one click.
Quick answer: A service account (or personal access token) is a standing credential tied to an application or a machine, not a person; it keeps working whether or not anyone is logged in. OAuth sign-in ties the connection to a person's own account and their existing session. In QueryFlow, BigQuery offers Sign in with Google (OAuth) or a service account JSON key; Databricks offers a personal access token or a service principal (OAuth machine-to-machine).
OAuth sign-in, "Sign in with Google" for BigQuery, is the credential you already use every day: it authenticates as you, through your existing browser session, and it inherits whatever access your account already has. It's the fastest way to get a personal connection working, and it renews itself the same way your Google session normally does.
A service account (Google's term) or a service principal (Databricks' term) is a credential that represents an application rather than a person. It has its own identity, its own permissions granted directly to it, and it keeps working regardless of who's logged into anything, which is exactly what a scheduled job running at 4 AM needs. A Databricks personal access token sits somewhere in between: it's tied to a specific person's account like OAuth, but it's a standing string you paste in rather than a live sign-in, so it also keeps working unattended.
| Connector | Personal option | Standing option |
|---|---|---|
| BigQuery | Sign in with Google | Service account JSON key (with BigQuery Job User + Data Viewer roles) |
| Databricks | Personal access token | Service principal, Client ID + Client Secret (OAuth M2M) |
Both options in each row work for querying, the Ask panel, Explorer and Watches. The choice mostly matters for who else relies on the connection and how well it needs to survive without you logged in.
Picking the personal option for a connection that turns out to need unattended reliability shows up as a specific, annoying failure mode: a scheduled job that worked fine for weeks suddenly stops, and the error traces back to an expired or revoked session rather than anything about the query itself. Picking the standing option for a connection only you ever use isn't wrong exactly, it just means an extra trip to Google Cloud Console or Databricks settings to create and manage a credential that a plain sign-in would have handled with one click.
A service account's JSON key or a Databricks personal access token can be revoked or regenerated independently of anyone's personal login, which matters when someone with access leaves the team. Revoke the standing credential in Google Cloud Console or Databricks, generate a new one, and update the connection in QueryFlow; nobody's personal Google or Databricks account needs to change. An OAuth-based personal connection is tied to that person's own session instead, so removing their access usually means removing them from the project or workspace directly.
If you're the only person using the connection and nothing needs it to run while you're logged out, the personal option (Sign in with Google, or a personal access token) is less setup and just as capable. If a scheduled job needs to run overnight, or a teammate needs the same connection without sharing your login, move to the standing option: a service account or service principal, granted only the roles that specific connection actually needs.
It can, but a personal sign-in is tied to your own session, so if your access is revoked or the session needs re-authentication, the job breaks along with it. A service account avoids that dependency.
Not inherently. A service account can actually be more contained, since you grant it only the specific roles a connection needs, rather than inheriting everything your own account can do.
Yes, edit the connection and change the Authentication method, then re-enter whichever credential the new method needs.
No. A token is a standing string tied to your account; OAuth (service principal) is a separate machine identity with its own client ID and secret. Both are options under Databricks' Authentication setting.
Pick the personal option for yourself, the standing one for anything unattended. Get QueryFlow →