How Looker Connects to Databases: A Beginner’s Guide to Secure, Live Data Connectivity

Learn how Looker connects securely to databases, generates SQL queries, and delivers live data to dashboards without storing your underlying business data.

When you start learning Looker, one of the first concepts you need to understand is how Looker actually accesses your data.

Unlike traditional BI tools that may import or extract data into their own storage layer, Looker is designed around a different approach: your data remains in the database, while Looker sends queries to that database and uses the returned results for analytics and visualization.

This architecture is one of the key concepts behind Looker’s approach to governed, centralized analytics.

In this article, we’ll explore:

• How Looker connects to databases
• Whether Looker stores your underlying data
• Which databases Looker can connect to
• How Looker Admins configure connections
• What happens when a user opens a dashboard
• How LookML is involved in SQL generation
• A practical example of the complete data flow
• Security considerations for Looker connections

1. How Does Looker Connect to a Database?

At a high level, Looker works as an analytics layer between users and the underlying database.

The basic architecture looks like this:

User → Looker Dashboard → LookML → SQL Query → Database → Query Results → Looker → Visualization

When a user interacts with a dashboard, Looker doesn’t need to copy the underlying business data into Looker’s own analytical database.

Instead, Looker generates SQL based on the user’s selections and sends that SQL to the connected database.

For example, imagine a user selects:

• Country = India
• Year = 2026
• Total Revenue
• Revenue by Product

Looker can generate a SQL query based on the LookML definitions and dashboard selections.

The database executes that query and returns the results.

Looker then uses those results to display charts, tables, single-value visualizations, and other dashboard components.

2. Does Looker Store Your Data?

One of the most important concepts for beginners is understanding the difference between storing data and querying data.

Looker primarily acts as a semantic and analytics layer over your existing data infrastructure.

Your underlying business data can remain in platforms such as:

• Google BigQuery
• Snowflake
• Amazon Redshift
• Azure Databricks
• Other supported SQL databases

When users interact with Looker, queries are generated and executed against the connected database.

Simplified example

Suppose your database contains:

orders
customers
products
payments

Looker doesn’t need to move all of these tables into Looker before users can analyze them.

Instead, Looker can generate SQL such as:

SELECT
    product_category,
    SUM(revenue) AS total_revenue
FROM orders
WHERE order_date >= '2026-01-01'
GROUP BY product_category
ORDER BY total_revenue DESC;

The database executes the query and returns the results.

Looker then visualizes those results.

Why is this important?

This architecture means organizations can continue using their existing data platforms while adding Looker as an analytics and semantic layer.

3. Looker Supports Multiple Database Platforms

Modern organizations rarely use a single database technology.

A company might use BigQuery for cloud analytics, Snowflake for its data warehouse, or Databricks for large-scale data processing.

Looker supports connectivity to a wide range of SQL-based data platforms.

Some commonly used platforms include:

Google BigQuery

BigQuery is Google’s cloud data warehouse and is widely used with Looker.

A typical architecture could look like:

Business Data
     ↓
BigQuery
     ↓
Looker
     ↓
Dashboards & Reports

Snowflake

Looker can connect to Snowflake and generate SQL that Snowflake executes.

Data → Snowflake → Looker → Users

Amazon Redshift

Organizations using AWS data infrastructure can connect Looker to Amazon Redshift for analytics.

Azure Databricks

Looker can also be connected to supported Databricks environments, allowing users to analyze data through Looker while keeping the underlying data platform in place.

The exact configuration depends on the database dialect, authentication method, network architecture, and organizational security requirements.

4. Who Creates a Looker Database Connection?

Database connections are generally managed by Looker Administrators.

A Looker Admin is responsible for configuring the connection and ensuring that Looker can securely communicate with the organization’s database.

Typical responsibilities include:

• Creating database connections
• Selecting the correct SQL dialect
• Configuring host information
• Configuring ports
• Providing authentication details
• Testing connections
• Managing connection settings
• Reviewing connection errors
• Applying appropriate security controls

This is an important distinction for Looker developers.

A LookML developer typically works with models, views, explores, dimensions, measures, joins, and other modeling components.

A Looker Admin, however, manages the infrastructure-level connection between Looker and the database.

5. What Information Is Required to Create a Connection?

The exact fields depend on the database platform and authentication method.

However, a connection commonly requires information such as:

Database Dialect

The dialect tells Looker which database technology it is communicating with.

Examples include:

BigQuery
Snowflake
Redshift
Databricks
PostgreSQL
MySQL

Different databases have different SQL syntax and capabilities, so selecting the correct dialect is important.

Host

The host identifies where the database server or service is located.

For example:

database.company.com

Cloud platforms may use platform-specific connection information instead.

Port

Some database connections require a network port.

For example:

5432

The correct port depends on the database technology and configuration.

Authentication

Authentication determines how Looker proves its identity to the database.

Depending on the platform, authentication may involve:

• Username and password
• Service accounts
• OAuth
• Key-based authentication
• Cloud-specific authentication mechanisms

For example, a BigQuery environment may use an appropriate Google Cloud authentication method or service account configuration.

6. What Happens When You Open a Looker Dashboard?

This is where the architecture becomes particularly interesting.

Imagine you open an executive sales dashboard.

The dashboard contains tiles such as:

Total Revenue
Total Orders
Revenue by Region
Revenue by Product
Monthly Sales Trend

You select:

Year = 2026
Region = APAC

What happens next?

Get Narayan Yadav’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Let’s break it down.

Step 1: User Interacts With the Dashboard

The user selects a filter:

Region = APAC

Looker receives this interaction.

Step 2: Looker Uses the LookML Model

Looker uses the underlying LookML model to understand:

• Which Explore should be queried
• Which view contains the required fields
• Which dimensions are available
• Which measures should be calculated
• How tables are joined
• What filters should be applied

LookML acts as the semantic layer that defines how users interact with the underlying data.

Step 3: Looker Generates SQL

Based on the user’s selections and the LookML definitions, Looker generates SQL.

For example:

SELECT
    region,
    SUM(revenue) AS total_revenue
FROM orders
WHERE region = 'APAC'
GROUP BY region;

The actual SQL generated by Looker will depend on the database dialect, model configuration, selected fields, filters, joins, and other factors.

Step 4: SQL Is Sent to the Database

Looker sends the generated query to the connected database.

For example:

Looker
   |
   | SQL Query
   ↓
BigQuery / Snowflake / Redshift / Databricks

The database is responsible for executing the query.

Step 5: Database Executes the Query

The database processes the query using its own compute engine.

For example:

Orders Table
     ↓
Filter APAC
     ↓
Aggregate Revenue
     ↓
Return Results

The database then returns the query results.

Step 6: Looker Displays the Results

Looker receives the results and presents them through the dashboard visualization.

For example:

APAC Revenue

$12.8M

Or perhaps a chart:

Revenue
  |
  |       █
  |   █   █
  | █ █   █
  | █ █ █ █
  +-------------
    Jan Feb Mar

The user sees the analytical result without needing to write SQL manually.

7. The Role of LookML

Understanding LookML is critical if you want to become a Looker Developer.

LookML defines the business logic and semantic structure that Looker uses when generating queries.

For example:

view: orders {
  dimension: order_id {
    primary_key: yes
    type: number
    sql: ${TABLE}.order_id ;;
  }
dimension: region {
    type: string
    sql: ${TABLE}.region ;;
  }
  measure: total_revenue {
    type: sum
    sql: ${TABLE}.revenue ;;
  }
}

A business user doesn’t necessarily need to know the underlying SQL.

Instead, they can select:

Region
Total Revenue

from the Explore.

Looker uses the LookML definitions to generate the appropriate SQL.

This is one of the major benefits of a semantic modeling layer.

8. Looker Architecture: A Simple Diagram

You can think about the overall architecture like this:

             BUSINESS USERS
                    |
                    ↓
             LOOKER DASHBOARD
                    |
                    ↓
                 EXPLORE
                    |
                    ↓
                 LOOKML
                    |
                    ↓
             SQL GENERATION
                    |
                    ↓
          ┌───────────────────┐
          │      DATABASE     │
          │                   │
          │ BigQuery          │
          │ Snowflake         │
          │ Redshift          │
          │ Databricks        │
          └───────────────────┘
                    |
                    ↓
              QUERY RESULTS
                    |
                    ↓
             LOOKER VISUALS

This simple architecture explains the relationship between the user, LookML, SQL, and the database.

9. Why This Architecture Matters

Looker’s approach provides several important benefits.

Centralized Business Logic

Business logic can be defined in LookML rather than recreated independently in every dashboard.

For example:

Revenue
Profit
Customer Count
Order Count
Conversion Rate

can be defined centrally.

This helps improve consistency across analytics.

Reduced Duplicate Logic

Without a semantic layer, different analysts might calculate the same metric differently.

For example:

Analyst A:
Revenue = SUM(order_amount)

Analyst B:
Revenue = SUM(order_amount - discount)
Analyst C:
Revenue = SUM(net_revenue)

A governed semantic model can establish consistent definitions for important business metrics.

Leverage Existing Data Infrastructure

Organizations can continue using their existing cloud data warehouse or database rather than creating another isolated copy of the data purely for BI.

Real-Time or Near-Real-Time Analysis

Because queries can be sent to the underlying database when users interact with Looker, the freshness of results can reflect the underlying database and its data-update processes.

However, “live” does not automatically mean every dashboard query is always completely uncached or instant.

Caching, persistent derived tables, aggregate tables, database performance, and other configurations can affect query behavior and freshness.

10. Security Is an Important Part of Database Connectivity

Connecting a BI platform to enterprise databases requires careful security configuration.

Organizations should consider:

• Authentication
• Authorization
• Network security
• Database permissions
• Encryption
• User access
• Service accounts
• Row-level access
• Data governance
• Credential management

Looker also provides various modeling and access-control mechanisms that can help organizations govern which users can access particular data.

For example, LookML can be used alongside access controls to implement governed access to data and analytics.

However, database-level permissions and organizational security policies remain important parts of the overall security architecture.

11. Looker vs Traditional Data Import

A simplified comparison can help explain the difference.

ApproachTraditional Import-Based BILooker-Style Database QueryingData locationOften copied/importedRemains in underlying databaseQuery executionBI engine may process imported dataDatabase executes generated SQLModelingOften in BI layerLookML semantic layerSQL generationDepends on toolGenerated from LookML + user selectionsData freshnessDepends on refreshDepends on database, caching, and configurationCentralized metricsTool-dependentStrong semantic modeling approach

This is a simplified conceptual comparison because modern BI platforms can support multiple architectures.

12. A Real-World Example

Imagine an e-commerce company with millions of orders.

Its data is stored in BigQuery:

BigQuery
│
├── customers
├── orders
├── order_items
├── products
└── payments

The company connects Looker to BigQuery.

A Looker developer creates:

customers.view.lkml
orders.view.lkml
products.view.lkml

Then creates an Explore:

explore: orders {
  join: customers {
    relationship: many_to_one
  }
join: products {
    relationship: many_to_one
  }
}

Now a business user can explore:

Orders
  ├── Customer
  ├── Product
  ├── Region
  ├── Order Date
  └── Revenue

The user selects:

Region = India
Year = 2026

Looker generates SQL based on the Explore and LookML model.

BigQuery executes the SQL.

The results return to Looker.

Looker displays the results in a visualization.

The complete flow is:

Business User
      ↓
Looker Dashboard
      ↓
Explore
      ↓
LookML
      ↓
Generated SQL
      ↓
BigQuery
      ↓
Query Results
      ↓
Looker Visualization

13. What Should a Beginner Remember?

If you’re new to Looker, remember these five concepts:

1. Looker is not simply a database

Looker is an analytics and semantic layer that works with your underlying data platform.

2. Your underlying data can remain in your database

Looker can query supported databases instead of requiring all underlying data to be copied into Looker.

3. LookML defines the semantic layer

LookML describes dimensions, measures, relationships, business logic, and other modeling behavior.

4. SQL is generated dynamically

User selections in Explores and dashboards can result in SQL queries generated according to the LookML model and database dialect.

5. The database does the heavy query processing

The connected database executes the SQL and returns results that Looker can visualize.

Conclusion

Understanding Looker’s database connectivity is fundamental to becoming a successful Looker Developer or LookML Developer.

The overall concept is straightforward:

Looker provides the semantic and analytics layer, while the connected database remains the primary source for the underlying data and query execution.

When a user interacts with a dashboard, Looker uses the LookML model to understand the requested analysis, generates SQL, sends that query to the database, receives the results, and presents them through dashboards and visualizations.

The complete journey can be summarized as:

User → Dashboard → Explore → LookML → SQL → Database → Results → Visualization

Once you understand this flow, many other Looker concepts become easier to learn — including Explores, Views, dimensions, measures, joins, derived tables, PDTs, caching, aggregate awareness, access filters, and dashboard optimization.

If you’re starting your Looker journey, this database connectivity concept is one of the best foundations to understand before moving deeper into LookML development.