Dialects that use these instructions
The following dialects share database setup requirements as described on this page:
- Cloud SQL for PostgreSQL
- Microsoft Azure PostgreSQL
- AlloyDB for PostgreSQL
- Amazon Aurora PostgreSQL
- Amazon RDS for PostgreSQL
Encrypting network traffic
Looker strongly recommends encrypting network traffic between the Looker application and your database. Consider one of the options described on the Enabling secure database access documentation page.
If you're interested in using SSL encryption, see the PostgreSQL documentation.
Users and security
some_password_here to a unique, secure password:
CREATE USER looker WITH ENCRYPTED PASSWORD 'some_password_here'; GRANT CONNECT ON DATABASE database_name to looker; \c database_name GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO looker; GRANT SELECT ON ALL TABLES IN SCHEMA public TO looker;
If you're using a schema other than
public, run this command to grant usage permissions to Looker:
GRANT USAGE ON SCHEMA schema_name TO looker;
To make sure that future tables you add to the public schema are also available to the
looker user, run these commands:
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON tables TO looker; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON sequences TO looker;
Depending on your setup, the preceding commands may need to be altered. If another user or role is creating tables that the
looker user needs future permissions for, you must specify a target role or user to apply the
looker user's permission grants for:
ALTER DEFAULT PRIVILEGES FOR USER <USER_WHO_CREATES_TABLES> IN SCHEMA public GRANT SELECT ON tables TO looker; ALTER DEFAULT PRIVILEGES FOR ROLE <ROLE_THAT_CREATES_TABLES> IN SCHEMA public GRANT SELECT ON sequences TO looker;
For example, if a
web_app user creates tables and you want the
looker user to be able to use those tables, you must run a
GRANT statement to give the
looker user permissions on tables that are created by the
web_app user. The target role/user in this case is the
web_app user, meaning we are targeting tables that are created by
web_app so that the
looker user can have permissions to read the tables. Here is an example:
ALTER DEFAULT PRIVILEGES FOR USER web_app IN SCHEMA public GRANT SELECT ON tables TO looker;
ALTER DEFAULT PRIVILEGES on PostgreSQL's website for more information.
Temp schema setup
Create a schema owned by the
CREATE SCHEMA looker_scratch AUTHORIZATION looker;
Postgres on Amazon RDS
Create a scratch schema:
CREATE SCHEMA looker_scratch;
Change the ownership of the scratch schema to the
ALTER SCHEMA looker_scratch OWNER TO looker;
Finally, you should set an appropriate
search_path, which Looker's SQL Runner uses to retrieve certain metadata from your database. Assuming you have created a user called
looker, and a temp schema called
looker_scratch, the command is:
ALTER USER looker SET search_path TO '$user',looker_scratch,schema_of_interest,public ^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^ include a comma-separated list of all schemas you'll use with Looker
Adding the connection
After completing the database configuration, you can connect to the database from Looker. In the Admin section of Looker, select Connections, and then click Add Connection.
Fill out the connection details. The majority of these settings are common to most database dialects. They are described on the Connecting Looker to your database documentation page.
After configuring the connection options, click on Test These Settings to verify that the connection to PostgreSQL is successful. See the Testing database connectivity documentation page for troubleshooting information.
Click Add Connection to save the connection.
For Looker to support some features, your database dialect must also support them.
In the latest release of Looker, PostgreSQL supports the following Looker features:
In the latest release of Looker, Cloud SQL for PostgreSQL supports the following Looker features:
In the latest release of Looker, Microsoft Azure PostgreSQL supports the following Looker features: