> ## Documentation Index
> Fetch the complete documentation index at: https://notikaai.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# FAQ

> Answers to common questions about Dreamlit, including setup, pricing, support, Supabase Auth, reliability, and security.

Looking for something else? These pages cover the most common topics:

<CardGroup cols={3}>
  <Card title="How it works" icon="gears" href="/docs/getting-started/how-it-works">
    Architecture and database-driven approach
  </Card>

  <Card title="Use cases" icon="lightbulb" href="/docs/getting-started/use-cases">
    Notification types and workflow examples
  </Card>

  <Card title="Quickstart" icon="rocket" href="/docs/getting-started/quickstart">
    Connect your database and create your first workflow
  </Card>
</CardGroup>

## Product and Use Cases

### What is Dreamlit?

Dreamlit is an AI-powered notification platform that runs on top of your PostgreSQL database. You describe the workflow in plain English, and Dreamlit builds and runs the trigger logic, templates, timing, and delivery.

### Who is Dreamlit for?

Dreamlit is built for teams that want production-quality notifications without adding more app-code complexity:

* **Vibe coders** using tools like Lovable, Bolt, Figma Make, or v0
* **Founders and small teams** shipping fast without dedicated email infrastructure work
* **Product and growth teams** that need to iterate on notifications without waiting on backend changes
* **Supabase users** who want stronger auth and transactional email flows

### How is Dreamlit's AI different from general coding assistants?

General coding assistants are broad. Dreamlit's AI is specialized for notifications.

* It is optimized for workflow design, timing, and message logic
* It reads your schema context to suggest practical triggers and conditions
* It asks clarifying questions when fields or relationships are ambiguous
* It keeps notification concerns separated from your app's core product code

### What types of notifications can Dreamlit handle?

Dreamlit supports the major notification categories most apps need:

* **Auth emails**: password reset, magic links, email verification
* **Transactional**: order confirmations, receipts, account updates
* **Scheduled and lifecycle**: digests, reminders, trial and renewal nudges
* **Onboarding and activation**: welcome flows, milestone nudges, re-engagement
* **One-off broadcasts**: launches, announcements, targeted campaigns
* **Internal alerts**: team notifications by email and Slack

See more examples in [Use cases](/docs/getting-started/use-cases).

## Setup and Integration

### Which setup guide should I follow?

Use the guide that matches your database hosting model:

* **Cloud-hosted Supabase**: Use the [Supabase setup guide](/docs/configuration/data-sources/supabase) for OAuth2 connection and automatic permission setup
* **Self-hosted Supabase or other Postgres hosts**: Use the [PostgreSQL setup guide](/docs/configuration/data-sources/postgres) with a dedicated `dreamlit_app` user and connection string

### How much does Dreamlit cost?

Dreamlit pricing depends on your usage and plan.

* For current plans and limits, see [Pricing](https://dreamlit.ai/pricing)
* If you need help choosing a plan for your volume, contact [Support](/docs/resources/getting-support)

### How do I get support?

Use the [Support page](/docs/resources/getting-support) for the fastest path to help.

* Include your workspace, workflow, and timestamp details when reporting an issue
* For setup blockers, include your database provider and where setup failed

### How does Dreamlit work with Supabase Auth?

For cloud-hosted Supabase projects, Dreamlit can handle Supabase Auth emails with custom templates.

* Auth emails are triggered from Supabase Auth API flows, not regular table-change triggers
* Dreamlit configures the needed auth hook during setup
* Your app still triggers auth events through standard Supabase auth methods

See [Supabase Auth setup details](/docs/configuration/data-sources/supabase#supabase-auth-emails). Supabase notes that default auth email setup is not intended for production use without proper SMTP configuration ([source](https://supabase.com/docs/guides/auth/auth-smtp)).

### Why does Dreamlit use the database instead of APIs?

Using the database as the event source reduces coupling and keeps notification execution aligned with your system of record.

| Concern         | Database-driven (Dreamlit)             | API-driven approach                               |
| --------------- | -------------------------------------- | ------------------------------------------------- |
| App coupling    | Low: app writes data as usual          | Higher: app must call/send notification APIs      |
| Event capture   | Data changes become events             | Events can be missed if calls are skipped or fail |
| Iteration speed | Update workflows without app redeploys | Notification changes often tied to code deploys   |

## Reliability and Performance

### Does Dreamlit affect database performance?

No. Dreamlit's database triggers are lightweight and non-blocking.

* Triggers run AFTER the relevant database operation, so your original query is never delayed
* Each trigger performs only a single INSERT into a separate `dreamlit` schema to log the event. No querying, no joins, no external calls.
* Even if a trigger fails, the underlying database operation still succeeds. Dreamlit wraps trigger logic in an explicit try-catch block.
* Database triggers in general are [highly performant with minimal overhead](https://infinitelambda.com/postgresql-triggers/). The "insert into a separate table" pattern is a common, battle-tested approach in database design.

### Can notification events get dropped or lost?

No. Dreamlit is designed for reliability.

* If Dreamlit is temporarily unavailable while your database is online, events continue to be logged in the Dreamlit-managed schema and are processed when Dreamlit recovers.
* If your database is unavailable, your database is unavailable: your app cannot write new events, so there are no new database-triggered events to process during that window.
* After connectivity is restored, Dreamlit resumes processing pending events in order.

### How does Dreamlit handle failures?

Dreamlit automatically retries failed workflow steps with exponential backoff to handle transient errors like network connectivity issues.

* If a workflow fails after exhausting all retries, it is marked as failed and you are notified
* You can configure custom error handling for specific workflows

### What happens if my database goes down?

If your database is fully unresponsive, your workflows pause until connectivity is restored. This is the same behavior as the rest of your application.

When your database comes back online, Dreamlit processes all accumulated events in the correct order. No notifications are lost during the downtime.

## Security and Data Protection

### Is my data secure with Dreamlit?

Yes. Dreamlit is designed with security as a core principle, not an afterthought.

* **Read-only access**: Dreamlit never edits, deletes, or inserts data in your application tables
* **Dedicated database user**: A separate `dreamlit_app` user with least-privilege permissions keeps Dreamlit isolated from the rest of your database
* **Double-encrypted credentials**: Your database credentials are encrypted at rest and never exposed in plaintext
* **Encrypted in transit**: All database connections use SSL/TLS
* **No persistent storage**: Your application data isn't stored outside your database. Events are processed and cleaned up automatically.
* **Cloud-hosted Supabase**: If you connect via the [Supabase guide](/docs/configuration/data-sources/supabase), permissions are set up automatically through OAuth2 with no credentials to manage
* **Self-hosted / other Postgres**: If you connect via the [PostgreSQL guide](/docs/configuration/data-sources/postgres), you control exactly which schemas and tables Dreamlit can access

For the full deep dive, see [Security](/docs/resources/security).

### What database permissions does Dreamlit need?

Dreamlit needs the minimum permissions required to monitor your tables and log events:

* **SELECT** on the schemas and tables you choose to monitor
* **CREATE TRIGGER** on those same tables
* **Full access** to the `dreamlit` schema (where events are logged and processed)

Dreamlit never writes to your application tables. For cloud-hosted Supabase, permissions are configured automatically through OAuth2. For self-hosted databases, you create a dedicated `dreamlit_app` user with exactly these permissions. See the [PostgreSQL setup guide](/docs/configuration/data-sources/postgres) for details.

## Working with Your Database

### What databases does Dreamlit support?

Dreamlit works with any PostgreSQL database. This includes cloud-hosted Supabase, self-hosted Supabase, Neon, Amazon RDS, Google Cloud SQL, Azure, Render, Railway, and any other Postgres-compatible host.

* **Cloud-hosted Supabase**: One-click OAuth2 connection with automatic permissions. [Setup guide](/docs/configuration/data-sources/supabase)
* **Everything else**: Standard connection string with a dedicated database user. [Setup guide](/docs/configuration/data-sources/postgres)

### What if the event I want to trigger on isn't in my database?

Most application events are already reflected in your database: user signups, payments, status changes, and so on. These are being persisted naturally as part of your app's operation.

If you find an event that isn't captured, add it to your data model. This is a best practice: your database should be the source of truth for all application state.

For cloud-hosted Supabase Auth users, auth events work differently through API hooks. [Learn more](/docs/configuration/data-sources/supabase#supabase-auth-emails)

### How do I avoid breaking notifications when changing my database schema?

Dreamlit workflows reference your table and column names. When you rename or remove columns that a workflow depends on, that workflow can break. A few strategies to keep things smooth:

1. **Add columns before removing old ones**: Deploy the new column, update your workflows, then drop the old column
2. **Test with preview**: Use Dreamlit's workflow preview to verify everything still works after schema changes
3. **Check workflow status**: After a migration, check your workflows dashboard for any errors

For schema migration best practices, see [making schema changes without breaking workflows](/docs/getting-started/how-it-works#making-schema-changes-without-breaking-workflows).

## References

* [Supabase Auth SMTP docs](https://supabase.com/docs/guides/auth/auth-smtp)
* [PostgreSQL trigger performance overview](https://infinitelambda.com/postgresql-triggers/)

***

Last validated: 2026-02-26
