Synced table pipeline fails with permission denied for database

KhaturiabPreet — Fri, 07 Aug 2026 17:43:47 GMT

Environment: Azure Databricks, Lakebase Autoscaling project. Database created through the Lakebase UI by the project owner (audit log shows createProjectBranchDatabaseUI with a browser user agent). Synced tables created via the databricks_postgres_synced_table Terraform resource, provider 1.122.0, scheduling_policy = TRIGGERED, create_database_objects_if_missing = true.

Symptom: Synced tables are created successfully in Unity Catalog and Terraform reports success, but every pipeline's initial load fails and the Postgres tables are never created. Status is SYNCED_TABLE_OFFLINE_FAILED. The surfaced message is only:

[SYNCED_TABLE_ERROR] Synced table pipeline failure. Instance: <endpoint>. Please contact Databricks support.

The real cause is two levels deep in the pipeline events:

ERROR: permission denied for database "<mydb>"

What we ruled out: we recreated the synced tables under two different creator identities, both of which already had CONNECT and CREATE on the database. Both failed identically. That matches the documented behaviour that a synced table is owned by databricks_writer_<dbid> rather than by the creator, and that changing the pipeline's Run as identity doesn't reassign it. So the creator's privileges are not the issue.

Diagnosis: pg_database.datacl showed the database's own writer role missing CONNECT, while both reader roles had it:

databricks_writer_<oid> = C -- CREATE only, no CONNECT
databricks_reader_<oid> = c
databricks_reader_<other> = c
databricks_superuser = C*T*c*

SELECT oid FROM pg_database WHERE datname = '<mydb>' confirmed <oid> is this database, so that is the correct writer role for it.

No synced table had ever succeeded in this database — the only Databricks-owned table was __db_system.unity_catalog_registration_status.

Fix: granting the missing privilege, as a databricks_superuser member:

GRANT CONNECT ON DATABASE <mydb> TO databricks_writer_<oid>;

All three pipelines completed on the next trigger, with no other change, and row counts matched the source exactly.

Questions:

1. Is it expected that a UI-created Lakebase database can have CREATE but not CONNECT on its own databricks_writer_<dbid> role? Or does this indicate a provisioning bug?
2. Is granting CONNECT to that role the supported fix, or is there a setup step we skipped? The docs warn that modifying system roles can affect instance behaviour, so I would rather not carry a workaround indefinitely.
3. Should this be a routine readiness check before adding a synced table to an existing database — particularly one created some time ago — and if so, is there a supported API for it rather than querying pg_database.datacl directly?

Re: Synced table pipeline fails with permission denied for database

amirabedhiafi — Mon, 10 Aug 2026 11:21:48 GMT

Hello @KhaturiabPreet !

I like you analysis it made me do some reading this morning to freshen up my memory.

I checked the the doc and I can say that databricks_writer_<dbid> being unable to CONNECT does not look like an expected state because it is the system role used to create and manage synced tables and synced tables themselves are owned by that role. .

The doc does not say that users need to manually grant CONNECT to databricks_writer_<dbid> as part of synced table setup since its prerequisites concern the Lakebase project, UC source and permissions create_database_objects_if_missing = true is also explicitly supported when creating the synced tablehttps://docs.databricks.com/aws/en/oltp/projects/sync-tables

Therefore, given that the database was created through the Lakebase UI and every synced table failed until the writer privilege was corrected this looks much more like provisioning or bug than a skipped setup step.

Another thingGRANT CONNECT explains and fixes the failure but I would not consider manual modification of the system role the ideal long term configuration procedure as standard PostgreSQL GRANT commands are the documented mechanism for Lakebase database privileges including database privileges. however databricks_writer_<dbid> is categorized as a system managed role used by internal services.

so this:

GRANT CONNECT ON DATABASE <database_name>
TO databricks_writer_<dbid>;

is a technically correct remediation in my opinion as demonstrated by all three pipelines immediately succeeding but I would open a DBKS support case and ask them to confirm whether that database was incorrectly provisioned.

There is another strong point supporting your case which is the documented behavior says changing the pipeline run as identity does not reassign synced table ownership so recreating under different user or SP identities would not fix an ACL problem on databricks_writer_<dbid>.

and yes checking effective CONNECT is a sensible temporary readiness check especially for older or existing databases but I would avoid parsing pg_database.datacl directly and yoy have has_database_privilege() specifically for checking database connection permissions.

For example:

SELECT
    has_database_privilege(
        'databricks_writer_<dbid>',
        '<database_name>',
        'CONNECT'
    ) AS writer_can_connect;

you could check both relevant database privileges:

SELECT
    has_database_privilege(
        'databricks_writer_<dbid>',
        '<database_name>',
        'CONNECT'
    ) AS writer_can_connect,
    has_database_privilege(
        'databricks_writer_<dbid>',
        '<database_name>',
        'CREATE'
    ) AS writer_can_create;

This is preferable to inspecting pg_database.datacl because it tests the effective permission including inherited or public privileges rather than requiring your automation to interpret PostgreSQL ACL strings.

I didn't find anything in the doc until now a documented lakebase management API that exposes effective PostgreSQL database grants directly.

The lakebase Postgres REST API is primarily for infrastructure or resource management and DBKS distinguishes that API from actual database access. So I think for an automated readiness test today executing has_database_privilege() over a PostgreSQL connection is the cleaner supported approach.

topic Synced table pipeline fails with permission denied for database in Data Engineering

Synced table pipeline fails with permission denied for database

Re: Synced table pipeline fails with permission denied for database