feat: add Supabase database connector

[aadityesh]

Adds full Supabase connector support across all layers:

• Ingestion: SupabaseSource (extends PostgresSource + MultiDBSource), SupabaseLineageSource, connection builder, service_spec, queries with SUPABASE_SYSTEM_SCHEMAS (auth, storage, realtime, extensions, graphql, etc.)
• Schema: supabaseConnection.json spec + databaseService.json enum entry
• Java: SupabaseConnectionClassConverter + ClassConverterFactory registration
• Profiler: PythonDialects.Supabase = "postgresql" (reuses pg dialect)
• UI: Supabase icon, connection form schema, DatabaseServiceUtils wiring, service icon map, generated enum updates, Supabase.md docs panel
• Tests: 6 unit tests covering connection, system schemas, data types, service type validation, pooler host support
• Test connection: supabase.json test connection definition

Describe your changes:

Fixes

I worked on ... because ...

Type of change:

• Bug fix
• Improvement
• New feature
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation

Checklist:

• I have read the CONTRIBUTING document.
• My PR title is Fixes <issue-number>: <short explanation>
• I have commented on my code, particularly in hard-to-understand areas.
• For JSON Schema changes: I updated the migration scripts or explained why it is not needed.

---

Summary by Gitar

• Refactored ingestion logic:
  • Removed MultiDBSource mixin from SupabaseSource in metadata.py.
• Enhanced filtering:
  • Implemented get_schema_names to filter out SUPABASE_SYSTEM_SCHEMAS during metadata extraction.
• Added test coverage:
  • Added test_system_schemas_are_filtered in test_supabase.py to verify schema exclusion logic.

_{This will update automatically on new commits.}

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[gitar-bot]

Code Review ✅ Approved 2 resolved / 2 findings

Supabase database connector integration now properly excludes system schemas and removes redundant MultiDBSource inheritance. The implementation is clean and verified.

✅ 2 resolved

✅ Bug: SUPABASE_SYSTEM_SCHEMAS defined but never used in extraction

📄 ingestion/src/metadata/ingestion/source/database/supabase/queries.py:27-38 📄 ingestion/src/metadata/ingestion/source/database/supabase/metadata.py:46
The SUPABASE_SYSTEM_SCHEMAS tuple is defined in queries.py and tested in the unit tests, but it is never actually referenced in metadata.py or any schema filtering logic. This means Supabase internal schemas (auth, storage, realtime, extensions, etc.) will be ingested as user data schemas, which is almost certainly not the desired behavior.

The Postgres connector uses POSTGRES_SYSTEM_SCHEMAS in its get_schemas or schema filtering logic. The Supabase source should similarly filter out these system schemas during schema enumeration.

✅ Quality: Redundant MultiDBSource in SupabaseSource class hierarchy

📄 ingestion/src/metadata/ingestion/source/database/supabase/metadata.py:46
SupabaseSource inherits from both PostgresSource and MultiDBSource, but PostgresSource already extends MultiDBSource. The redundant explicit inheritance is unnecessary and slightly confusing about the design intent.

Options

Display: compact → Showing less information.

Comment with these commands to change:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[ulixius9]

@aadityesh I'm curious why do we need this connector, what is missing in the current postgres connector because of which we need to develop a Supabase connector?

[aadityesh]

Great question! Here's what the Postgres connector doesn't handle for Supabase:

System schema filtering: Supabase projects include several internal schemas (auth, storage, realtime, extensions, graphql, supabase_functions, etc.) that are platform internals, not user data. The Postgres connector would ingest all of these as noise. SupabaseSource overrides get_schema_names() to filter them out automatically.

Connection UX: Supabase has two distinct hostPort formats (direct connection and PgBouncer pooler) and enforces SSL by default. The dedicated connector surfaces this in the docs panel and defaults SSL mode to require.

Discoverability: Users searching for "Supabase" would never think to look under "Postgres". A named connector with the Supabase icon makes it immediately findable.

The ingestion logic fully reuses PostgresSource. The connector is intentionally thin and only adds what is Supabase-specific on top.