Looker Database
You set up a looker database link by pairing a dedicated database role with your reporting app. The app uses this role to run SQL queries and build charts for your team. Most teams create one shared service account with broad read rights across many schemas. When that role has too much power, any report user can pull sensitive rows by mistake. How a looker database setup works Looker does not hold your core business data inside its own local storage. Instead, it acts as a query builder that t
Database Access Proxy: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a looker database link by pairing a dedicated database role with your reporting app. The app uses this role to run SQL queries and build charts for your team. Most teams create one shared service account with broad read rights across many schemas. When that role has too much power, any report user can pull sensitive rows by mistake.
How a looker database setup works
Looker does not hold your core business data inside its own local storage. Instead, it acts as a query builder that talks straight to your data warehouse. You start the setup by creating a specific user role inside your SQL engine. Next, you grant that role permission to read the schemas and tables your analysts need. You also give it scratch space if the app needs to write temp tables. Then you save the host details and login keys inside the reporting app settings. When a user opens a dashboard, the app writes a fresh SQL query based on your model. It sends that query to the database over an encrypted network link. The database runs the job, returns the result set, and the app draws the chart. Your network team also needs to allow traffic between the app servers and the database port. Many teams use private network links or SSH tunnels to keep this traffic off the public web.
What native roles solve and what they miss
Native database roles and app modeling rules solve basic access control well. You can limit which tables the reporting tool can see inside the warehouse. You can also set up user attributes inside the app to filter rows or hide specific columns. This stops normal dashboard viewers from browsing tables that belong to other departments. Still, this setup still leaves a major security gap during live operations. The database only checks who logs in at the start of the session. Because the app uses a single shared service account, the database sees every query as the same user. This makes audit logs inside the warehouse very hard to tie to a single person. Worse, analysts often use the built-in SQL runner tool to test raw queries by hand. Those ad-hoc queries bypass the modeling layer and use the full power of the shared database role. Native roles cannot inspect individual SQL statements in flight or rewrite sensitive fields like emails, phone numbers, or card numbers in query results. If a table holds raw customer data, a broad select statement will return all of it to the screen.
Steps to tighten query control and data privacy
To reduce risk, start by splitting your single service account into smaller, scoped database roles. Create one database link for finance reports and a separate link for marketing data. Give each database role select rights on only the exact tables needed for that group. Avoid granting broad schema privileges that cover future tables by default. You should also restrict who can use the raw SQL runner tool inside your reporting app. Limit that feature to a small group of data engineers who build the data models. Even with these steps, teams still need a way to inspect queries and mask sensitive fields like national IDs in results.
Database Access Proxy: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does Looker store my data inside its own servers?
No, the app leaves your records inside your own SQL database. It sends live queries to your warehouse and only caches temporary chart results for speed.
Why do database logs show one user for all report queries?
Most teams set up the database link with one shared service account. The database records that single account name for every query the reporting app sends.
How can I protect emails and card numbers in SQL runner?
App model rules do not apply when analysts write raw queries in SQL runner. You need database masking rules or query inspection controls to rewrite those fields in results.