Data Connect ignores datasource.postgresql.schema and always qualifies objects with public #9271
Description
Firebase Data Connect appears to ignore the schema property under datasource.postgresql in dataconnect.yaml and continues to generate SQL that explicitly references objects in the public schema (e.g. "public"."vw_bible_faiths_localized"). Because the runtime SQL is explicitly qualified with public, the configured search_path or granting permissions does not fix the problem. This makes it effectively impossible to use a different Postgres schema (for example bible_content) with Data Connect — the server continues to run queries against public and fails when objects live in another schema.
I will list everything we tested and all artifacts (configs, diffs, schema, steps) so this is reproducible.
Environment
firebase-tools version: 14.18.0
Data Connect serviceId: dailybiblepuzzle-service
location: us-east4
Cloud SQL / Postgres:
instanceId: dailybiblepuzzle-instance
database: dailybiblepuzzle-database
target schema with actual objects: bible_content
CLI commands used: firebase dataconnect:sql:diff, firebase dataconnect:sdk:generate, firebase deploy --only dataconnect (with --debug), firebase dataconnect:sql:apply
Tried UI: VS Code Data Connect extension (Add SDK to App) and CLI.
What I configured locally
dataconnect/dataconnect.yaml (relevant parts)
specVersion: "v1"
serviceId: "dailybiblepuzzle-service"
location: "us-east4"
schema:
source: "./schema"
datasource:
postgresql:
schema: "bible_content" --> this parameter does not exist in oficial documentation
database: "dailybiblepuzzle-database"
cloudSql:
instanceId: "dailybiblepuzzle-instance"
schemaValidation: "COMPATIBLE"
connectorDirs: ["./connector"]
What actually happens (observed runtime / debug output)
When calling the published endpoint (or when running firebase dataconnect:sql:diff) the runtime generates SQL that references public explicitly. Example error payload returned by the Data Connect service:
"debugDetails": "cannot prepare SQL statement:
SELECT coalesce(json_agg(j), '[]') FROM (
SELECT jsonb_build_object('code', \"code\", 'religionNameLocal', \"religion_name_local\", 'traditionNameLocal', \"tradition_name_local\", 'descriptionLocal', \"description_local\") AS j
FROM \"public\".\"vw_bible_faiths_localized\"
WHERE ((((\"active\") = (true)) OR ((\"active\") IS NULL AND (true) IS NULL))
AND CASE WHEN ( $1 ::boolean) THEN ((((\"lang_code\") = ( $2 ::text)) OR ((\"lang_code\") IS NULL AND ( $3 ::text) IS NULL))) ELSE (true) END)
LIMIT 100) AS x
SQL Error: pq: relation \"public.vw_bible_faiths_localized\" does not exist"
Even though the view vw_bible_faiths_localized exists in bible_content schema (verified), the service is generating SQL against public and fails.
Many teams use schema separation in a single Postgres database (for organization, multitenancy, or separation of concerns). Data Connect should correctly honor the configured schema target or allow fully qualified schema.table names in the GraphQL mapping.
If Data Connect always qualifies objects with public (or interprets user-supplied names wrongly), it prevents safe adoption for systems that do not want to put objects into public.
Creating aliases in public is a poor workaround (duplication, maintenance, possible security exposure).
Thanks — we like the Data Connect concept a lot. We just need a way to map Data Connect to non "public" schemas (or confirmation of the intended behavior and documentation).