Connect Supabase, PostgreSQL, and MySQL to DataFact

DataFact now supports three additional structured-data connection choices: Supabase, PostgreSQL, and MySQL.

The new options let teams connect operational and analytical databases directly to governed DataFact workflows. An Agent can work with the schemas made available through that connection while the organization keeps network access, credentials, database permissions, and selected data scope under separate control.

The important change is not simply a larger connector list. It is a clearer route from an approved database to analysis that remains bounded by explicit configuration.

What was added

• Supabase for teams whose application data lives in a Supabase project.
• PostgreSQL for PostgreSQL services managed in cloud or private environments.
• MySQL for operational and analytical data stored in MySQL.

Supabase is PostgreSQL-compatible, but DataFact presents it as a distinct connection choice so teams can follow the connection configuration of the intended Supabase project. This is a product integration choice, not a claim that Supabase is a separate database engine.

The connection type identifies how DataFact should reach the source. It does not decide which data an Agent should use. That scope still comes from the database identity, the schemas selected during configuration, and the resources attached to the Agent.

Connect a database source

Start in Databases and choose Add Database. Select Supabase, PostgreSQL, or MySQL, then enter the connection information requested by the current form.

For Supabase, use the PostgreSQL connection details for the intended project. Choose a direct or pooled endpoint that is reachable from the DataFact deployment and allowed by your organization’s network policy. For PostgreSQL and MySQL, use the host, port, database, username, and password for the service you intend to query.

Then:

1. Test the connection.
2. Confirm that the expected schemas are returned.
3. Select only the schemas needed for the workflow.
4. Save the connection.

See the database connection guide for the current form and validation flow.

Treat connection and authorization as different checks

A successful connection test establishes that DataFact can reach the endpoint and authenticate with the supplied credentials. It does not establish that every table visible to those credentials is suitable for analysis.

That distinction matters because a technically valid database account can still be too broad. It may expose schemas outside the intended business domain, include sensitive operational tables, or allow write operations that an analytical workflow does not need.

Use a dedicated, least-privilege database identity where your operating policy allows it. Limit its permissions to the required databases and schemas, and select only the schemas needed by the Agent’s intended questions.

Data access should remain layered:

network reachability
        ↓
database credentials and permissions
        ↓
selected schemas
        ↓
Agent resources and execution controls

Each layer answers a different question. Reachability asks whether DataFact can contact the service. Authentication asks whether the identity is accepted. Schema selection asks which structures enter the configured source. Agent configuration asks which resources a particular workflow can use.

Preserve semantic and row-level controls

Connecting a database does not remove the need for governed definitions. Business metrics, joins, filters, and time logic still need an authoritative home so the same question does not produce different interpretations across teams.

Row-level restrictions also belong in enforceable data or query controls, not in a conversational instruction that can be omitted or misunderstood. The connected identity and downstream execution path should preserve the requester’s allowed data scope.

This is especially important for shared operational systems. A schema may be appropriate for an Agent while particular rows, columns, or tenant records remain restricted.

A practical connection checklist

Before making a new source available to an Agent, verify:

1. The endpoint is reachable from the intended DataFact environment.
2. The connection uses a dedicated identity where possible.
3. The identity has the required permissions and no unnecessary write access.
4. The connection test succeeds with the production-equivalent network path.
5. The expected schemas are returned.
6. Only schemas required by the workflow are selected.
7. Sensitive tables and fields have an explicit access decision.
8. Business definitions used by the Agent match the organization’s governed definitions.
9. A representative allowed query returns the expected result.
10. A request outside the intended scope does not expose restricted data.

Testing both the allowed and denied paths is essential. A successful example proves that one query works; it does not prove that the boundary holds.

Why these data sources matter

Supabase, PostgreSQL, and MySQL hold much of the operational context teams need for day-to-day decisions. Supporting them directly reduces the need to copy data into an intermediate system solely to make it available for analysis.

The value comes from making approved structured data usable without collapsing governance into a connection string. DataFact keeps the path explicit: connect the source, validate it, select the scope, attach the right resources, and test the resulting boundary.

Explore DataFact’s governed data analysis or review the database documentation.