You might want an extra guarantee that Lucien can never change your database – only read from it.

The best way to do that is to create a dedicated read‑only user in Postgres and use that account for the Lucien integration.

Who this is for

This page is written for your technical co‑founder or a trusted engineer. If you’re a non‑technical founder, you don’t need to run these commands yourself – just forward this page and share your intent.

1. Principle

We want a database user that:

• Can connect to your production Postgres instance.
• Can run SELECT, COUNT, WITH and similar read-only queries on your database schemas/tables.
• Cannot INSERT, UPDATE, DELETE, or ALTER anything.
• Is used only by Lucien.

You can scope access as narrowly as you like (for example: just analytics tables, or just the public schema).

2. Talk to your technical person

If you’re the non‑technical founder, this is what to say to your technical co‑founder / team:

"Please create a read‑only Postgres user for Lucien. It should only have read-only permissions on the tables we’re comfortable exposing for analytics (usage, subscriptions, etc.), and no ability to change data. Once it’s created, give me the connection URL so I can plug it into Lucien."

Then share this page plus the Connect Postgres page with them.

3. Example approach (for engineers)

Note: This is an example pattern – your exact commands will depend on your cloud provider and security policies.

1. Connect to your Postgres instance as a superuser or admin (for example: psql as postgres or an admin role).

2. Create a dedicated user (role) for Lucien:

CREATE ROLE lucien_readonly WITH LOGIN PASSWORD 'a-strong-secret-password-here';

3. Revoke default write permissions on the target database/schema, then grant read‑only access.

A common pattern for the public schema is:

-- replace "my_database" with your database name
\c my_database

-- revoke write access from PUBLIC if you haven’t already
REVOKE INSERT, UPDATE, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA public FROM PUBLIC;

-- grant read-only access to the Lucien user
GRANT CONNECT ON DATABASE my_database TO lucien_readonly;
GRANT USAGE ON SCHEMA public TO lucien_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO lucien_readonly;
-- WITH (CTE) read-only statements are allowed via SELECT privileges

-- ensure future tables in this schema are also readable
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO lucien_readonly;

If you keep analytics data in a separate schema (for example: analytics), repeat the USAGE / SELECT grants there instead of public.

4. Test the user by connecting with it and running a simple read query:

psql "postgres://lucien_readonly:password@host:5432/my_database"

SELECT 1;        -- should work
WITH check_cte AS (SELECT 1 AS ok) SELECT ok FROM check_cte; -- should work
INSERT INTO ...; -- should fail with a permissions error

5. Once you’re happy with the permissions, build a connection URL:

postgres://lucien_readonly:password@HOST:PORT/DATABASE

Share this URL (and any required SSL settings) with your non‑technical founder so they can use it in the Connect Postgres flow inside Lucien.

4. Keep permissions tight

A few final recommendations:

• Use a strong, unique password for the lucien_readonly user.
• Avoid granting this user to other apps – keep it dedicated to Lucien.
• If you ever want to revoke Lucien’s access, you can disable or drop this user, or rotate its password and update the integration.

Combined with Lucien’s internal safeguards and encryption (see lucienai.io/security), this gives you a very strong story when someone asks: "Are we sure this AI can’t touch production?"