Budibase/budibase · error

Found ${visibleNames.length} table(s) in the "${this.config.

Error message

Found ${visibleNames.length} table(s) in the "${this.config.schema}" schema (${visibleNames.join(", ")}), but none of their columns could be read. The datasource user is likely missing SELECT privilege on them - granting USAGE on the schema alone is not sufficient.

What it means

Postgres integration's getTableNames queries information_schema for columns; if zero columns are returned, it checks whether any tables are at least visible in the configured schema. When tables are visible but no columns can be read, it throws this error because the datasource user lacks SELECT (column-level read) privileges - USAGE on the schema only grants visibility, not column reads.

Source

Thrown at packages/server/src/integrations/postgres.ts:556

  async getTableNames() {
    try {
      await this.openConnection()
      const columnsResponse: { rows: PostgresColumn[] } =
        await this.client.query(this.COLUMNS_SQL())
      const names = [
        ...new Set(columnsResponse.rows.map(row => row.table_name)),
      ]

      if (names.length === 0) {
        const visibleTablesResponse = await this.client.query(
          this.VISIBLE_TABLES_SQL()
        )
        const visibleNames = visibleTablesResponse.rows.map(
          row => row.table_name
        )
        if (visibleNames.length > 0) {
          throw new Error(
            `Found ${visibleNames.length} table(s) in the "${
              this.config.schema
            }" schema (${visibleNames.join(
              ", "
            )}), but none of their columns could be read. The datasource user is likely missing SELECT privilege on them - granting USAGE on the schema alone is not sufficient.`
          )
        }
      }

      return names
    } finally {
      await this.closeConnection()
    }
  }

  async getViewNames() {
    try {
      await this.openConnection()

View on GitHub (pinned to a81a902e9a)

Solutions

  1. Grant SELECT on the schema's tables: GRANT SELECT ON ALL TABLES IN SCHEMA <schema> TO <user>;
  2. Add ALTER DEFAULT PRIVILEGES IN SCHEMA <schema> GRANT SELECT ON TABLES TO <user>; so future tables are covered
  3. Verify with the datasource user: SELECT * FROM information_schema.columns WHERE table_schema='<schema>'; should return rows
  4. Check for column-level privileges/REVOKE or row-level security policies that hide columns from the role
  5. If only a subset of tables should be readable, grant SELECT on those specific tables

Example fix

// before (psql as superuser)
GRANT USAGE ON SCHEMA public TO bb_readonly;
// after
GRANT USAGE ON SCHEMA public TO bb_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO bb_readonly;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO bb_readonly;
Defensive patterns

Strategy: validation

Validate before calling

// Run as the datasource user before listing tables:
const { rows } = await client.query(
  "SELECT COUNT(*)::int AS n FROM information_schema.columns WHERE table_schema = $1",
  [schema]
)
if (rows[0].n === 0) {
  throw new Error(
    `User cannot read columns in schema "${schema}" - grant SELECT on its tables`
  )
}

Try / catch

try {
  await datasource.getTableNames()
} catch (e) {
  if (String(e.message).includes("missing SELECT privilege")) {
    // surface a DBA action: GRANT SELECT ON ALL TABLES IN SCHEMA <schema> TO <user>
  } else { throw e }
}

Prevention

When it happens

Trigger: Calling getTableNames (table listing/fetch during datasource schema fetch) when the COLUMNS_SQL() query returns zero rows but VISIBLE_TABLES_SQL() finds tables in this.config.schema - i.e. the connecting role has USAGE on the schema but no SELECT privilege on any of its tables.

Common situations: Admin creates a Postgres user with GRANT USAGE ON SCHEMA public TO user but forgets GRANT SELECT ON ALL TABLES; roles like read-only users provisioned by cloud RDS without default privileges for future tables; row-level security blocking column reads; connecting to a restricted schema in production DBs.

Related errors


AI-assisted analysis of Budibase/budibase@a81a902e9a (2026-08-29). Data as JSON: /api/errors/7358eb62a26ca929. Report an issue: GitHub.