Connect Supabase, PostgreSQL, and MySQL—Then Ask in Slack or Telegram

DataFact now supports three new structured-data connection choices—Supabase, PostgreSQL, and MySQL—and two new native messaging channels—Slack and Telegram.

Together, these additions shorten the path between a governed database and the place where a question is already being asked. A team can connect an approved database, make selected schemas available to an Agent, and let people work with that Agent from Slack or Telegram instead of moving every question into a separate console.

That does not make data access and message delivery the same thing. They are two separate layers with separate controls, and keeping that distinction visible is essential for a trustworthy rollout.

What was added

The release expands DataFact at both ends of an Agent workflow.

Structured-data sources

• 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.

Messaging channels

• Slack for Agent conversations in Slack workspaces.
• Telegram for Agent conversations through a configured Telegram bot.

They join the existing DingTalk and Feishu options. Teams and custom applications can still use the open API when a native channel is not the right delivery path.

One workflow, two boundaries

The data source determines what structured information an Agent can work with. The messaging channel determines where a person can talk to that Agent. An Agent sits between those layers and applies its own resources, behavior, and permissions.

Supabase / PostgreSQL / MySQL
              ↓
     selected schemas and access
              ↓
          DataFact Agent
              ↓
 Slack / Telegram / DingTalk / Feishu

This separation prevents several misleading assumptions:

• Registering Slack does not grant Slack users access to every connected database.
• Connecting a database does not publish an Agent to any messaging platform.
• A successful connection test does not prove that every table is appropriate for analysis.
• Saving channel credentials does not prove that external app or bot delivery is fully configured.

Each boundary must be configured and checked independently.

Connect Supabase, PostgreSQL, or MySQL

Start in Databases and choose Add Database. Select the source that matches the target environment, 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.

Use a dedicated, least-privilege database identity where your operating policy allows it. A source becoming technically reachable should not expand the data scope beyond what the intended analysis requires.

See the database connection guide for the current flow.

Register Slack or Telegram

Open Applications, create a channel, and select Slack or Telegram. The form displays the provider-specific values required by the released integration. Obtain those values from the corresponding app or bot configuration in the external platform.

We deliberately do not reduce every channel to a generic “App ID and App Secret” model. Slack, Telegram, DingTalk, and Feishu have different provider contracts. The current DataFact form is the source of truth for required fields, validation, and credential rotation behavior.

After the channel is saved, connect it from an editable General Agent’s configuration. The registration and the Agent association are separate steps; this prevents a newly created external channel from being implicitly attached to an Agent.

See the channel creation guide and Agent connection guide for details.

Keep governance intact outside the console

Moving the conversation into Slack or Telegram should not move governance into the chat prompt. The Agent’s data resources and execution controls remain the authority for what it can retrieve or query.

For structured data, that means using the intended database identity, limiting selected schemas, maintaining business definitions, and applying table- or row-level controls where the workflow requires them. For delivery, it means protecting provider secrets, controlling who can reach the app or bot, and validating the external platform setup.

The channel also has presentation controls for reasoning and tool messages. Those settings affect what execution details are forwarded to the messaging platform; they do not grant or revoke the Agent’s tools.

A practical release checklist

Before enabling a team, verify the full path rather than testing each screen in isolation:

1. The database endpoint is reachable from the intended DataFact environment.
2. The connection uses a dedicated identity with the required—and no broader—permissions.
3. The connection test succeeds and returns the expected schemas.
4. Only the schemas needed by the Agent are selected.
5. The Slack app or Telegram bot is active and configured in the intended workspace or chat environment.
6. Provider secrets are stored through the channel form and have not been copied into tickets or screenshots.
7. The channel is connected to the intended General Agent.
8. A representative user can ask a scoped question and receive the expected answer in the external channel.
9. A user outside the intended data scope cannot retrieve restricted results.
10. Failed delivery and credential rotation have an identified owner and recovery procedure.

This checks both capability and boundary behavior. A successful happy-path answer alone is not enough for an enterprise rollout.

Why these integrations matter

Database integrations make more operational facts available to governed analysis. Native messaging integrations reduce the context switch required to use that analysis. The useful outcome is not a larger connector count; it is a shorter, inspectable path from approved data to the people making a decision.

That path remains explicit: connect the source, select the scope, configure the Agent, register the channel, and verify end-to-end behavior. DataFact does not treat “connected” as a synonym for “authorized,” or “saved” as a synonym for “delivered.”

Explore DataFact’s governed data analysis or see how Data Agents deliver results.