Question 1

Will connecting this slow down my production Cloud SQL for PostgreSQL database?

Accepted Answer

Profiling reads a sample when the source first connects, not your whole table and not on a loop. After that a query only runs when someone asks a question or a dashboard refreshes, and nothing polls your database in the background. That said, we do not recommend pointing dashboards or AskEdi at a production database. Analytical queries and transactional workloads compete for the same resources, and a dashboard refreshing on a schedule is load your application does not need. Use Transform to clean the data and write it to a warehouse or lake such as Snowflake, BigQuery, Redshift or Databricks, then point Visualize and AskEdi at that instead. Connecting Cloud SQL for PostgreSQL as a source to profile it and build that pipeline is exactly what it is for.

Question 2

Does Edilitics need write access to my Cloud SQL for PostgreSQL database?

Accepted Answer

It depends on how you use it. Read access is enough to connect, profile, build dashboards and ask questions, which is everything except one case. Read and write are both needed only if you choose this database as a destination in Transform, because a pipeline creates and populates a table there. If you never write results back, a read-only role covers everything.

Question 3

What do I need to open up on my network for Cloud SQL for PostgreSQL?

Accepted Answer

Add the Edilitics static IP addresses to the authorised networks list on your Cloud SQL instance. Scope the role to the specific database you want to use, and keep it read-only unless you plan to write pipeline results back to it.

Question 4

Can the AI reach data the person asking cannot?

Accepted Answer

The AI never has access to your database or your credentials at all. It receives column names, types and quality statistics, and what it returns is text: a proposed query, nothing more. That query is then validated by Edilitics before anything runs - it must be a read-only SELECT, and anything else is rejected outright rather than corrected. Only after it passes does the Edilitics server execute it, using your stored credentials and the permissions already enforced on them. So the AI cannot reach your data directly, and the query it proposed cannot return anything your own role could not read.

Question 5

If I share a Cloud SQL for PostgreSQL connection with a colleague, do they get my credentials?

Accepted Answer

No. Credentials are encrypted with a key derived per workspace and are never returned to a shared user. They can query the connection, build on it and read its quality grades, but never see the host, password or connection string. Only you and workspace admins can edit, delete, re-share or refresh it.

Question 6

Do my actual rows ever reach an AI provider?

Accepted Answer

No, on every plan and in every privacy mode. Your records are never stored on Edilitics infrastructure either - what is stored is schema metadata, configuration and conversation history, each encrypted with a per-workspace key.

Ask your Cloud SQL for PostgreSQL database directly, while you are still in the meeting.

Connect PostgreSQL GCP once,
then use it four ways.

Read PostgreSQL GCP where it already lives

Clean and reshape PostgreSQL GCP data without SQL

Track it on a dashboard that rebuilds itself

Ask it questions in plain English

Know what your PostgreSQL GCP data is worth
before you trust a number from it.

Every column graded A to F, with no setup

Every column described in plain English

Your wording wins, permanently

You see what breaks before it breaks

Write analytics-ready PostgreSQL GCP data
to any destination.

PostgreSQL GCP is the starting point.
Here is what it feeds.

Everything you need to know about the PostgreSQL GCP Connector.