Skip to main content
Looking for something else? These pages cover the most common topics:

How it works

Architecture and database-driven approach

Use cases

Notification types and workflow examples

Quickstart

Connect your database and create your first workflow

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.

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 for OAuth2 connection and automatic permission setup
  • Self-hosted Supabase or other Postgres hosts: Use the PostgreSQL setup guide 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
  • If you need help choosing a plan for your volume, contact Support

How do I get support?

Use the Support page 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. Supabase notes that default auth email setup is not intended for production use without proper SMTP configuration (source).

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.
ConcernDatabase-driven (Dreamlit)API-driven approach
App couplingLow: app writes data as usualHigher: app must call/send notification APIs
Event captureData changes become eventsEvents can be missed if calls are skipped or fail
Iteration speedUpdate workflows without app redeploysNotification 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. 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, permissions are set up automatically through OAuth2 with no credentials to manage
  • Self-hosted / other Postgres: If you connect via the PostgreSQL guide, you control exactly which schemas and tables Dreamlit can access
For the full deep dive, see 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 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
  • Everything else: Standard connection string with a dedicated database user. Setup guide

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

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.

References


Last validated: 2026-02-26