Dreamlit leverages an event-driven architecture with your database as the source of truth. It is designed to be secure, efficient, and performant. On a high level, here’s how it works:

1. Connect your app

Our guided setup flow walks you through securely connecting your database and configuring your email sender.

2. Create and publish a workflow

Use our AI workflow builder to setup your workflow from end-to-end, starting with a database trigger. Publish the workflow to securely install it.

3. Sit back and relax

When the trigger condition is met, Dreamlit handles the rest. The workflow is executed in real-time, and notifications are delivered to your users.
Database compatibility: Dreamlit currently works with Supabase and PostgreSQL databases. We’re actively working on support for additional databases.

​
How Dreamlit works with your app

1

App persists events

Your application simply writes to the database when something happens - a user signs up, a payment is processed, or any business event occurs. These events are likely already being persisted naturally as part of your app’s normal operation. No need to worry about notification logic or add special code.
2

Database as source of truth

Your database remains the single source of truth.
3

Dreamlit monitors & executes

Dreamlit continuously monitors for new events and executes the appropriate workflows when trigger conditions are met, handling all the complexity of scheduling, retries, and delivery.
This architecture provides clear separation of concerns - your app focuses on core business logic and user experience, while your notification logic and workflows are separated out in Dreamlit. The database serves as the reliable bridge between them.
Using Supabase Auth? Auth emails work slightly differently through API hooks. Learn more about Supabase Auth configuration →

​
Why separate notifications from your app code?

​
AI works better with focused scope

When you try to build everything in one place—app logic, UI, and notifications—you’re asking AI to juggle too many concerns at once. This cognitive overload leads to mediocre results across the board. By separating notifications into Dreamlit:
  • Your app’s AI (whether in Cursor, Lovable, Bolt, or Replit) can focus solely on user experience and business logic
  • Dreamlit’s AI specializes exclusively in notifications
  • Each AI operates at peak performance in its domain, rather than struggling with competing priorities

​
Notifications are a different beast

Notifications are fundamentally different from in-app interactions. They require:
  • Template design and previews across email clients and devices
  • Delivery timing and scheduling (wait steps, business hours, time zones)
  • Engagement tracking (opens, clicks, unsubscribes)
  • Compliance handling (CAN-SPAM, GDPR, unsubscribe management)
These concerns don’t belong mixed with your app’s user interface code. By keeping them separate, each system can excel at what it does best.

​
Database as the perfect intermediary

Your database schema is inherently self-documenting—it tells both systems exactly what data exists and how it’s structured. This makes it the ideal boundary between your app and notification system:
  • No API contracts to maintain - The database schema IS the contract
  • Natural event sourcing - Data changes are events by definition
  • Context is built-in - Table relationships and column names provide the context AI needs, and when schemas are ambiguous, Dreamlit’s AI proactively asks clarifying questions
  • Zero coupling - Your app doesn’t know Dreamlit exists, and vice versa

​
Battle-tested architecture pattern

This isn’t a new pattern—it’s how enterprise systems have been built for decades:
  • Event-driven architecture using your existing database as the event store
  • Microservices boundary without the complexity of service meshes or API gateways
  • Future-proof flexibility - Swap out either system without touching the other
The result? Each tool does one thing exceptionally well, rather than multiple things poorly. Your notifications become as polished as your app, without compromising either.

​
Architecture deep dive

When a workflow is published, Dreamlit adds a tiny database trigger on the relevant table that simply logs an event within the event_log table in a separate dreamlit schema. From there, Dreamlit periodically efficiently polls this event_log table, and launches workflows when new events are detected. This approach allows for a secure, efficient, and reliable way to listen for events and handle your workflows:
  • Virtually no impact on database performance: database triggers are highly efficient and non-blocking.
  • Even in the unlikely event that Dreamlit is temporarily down (our uptime is 99.9+%), events will continue to accrue. When Dreamlit is back online, it will pick up where it left off and fire off any unprocessed events.
  • After the event is picked up, Dreamlit handles each step in a robust, durable manner, automatically retrying any failed steps.

​
The lifecycle of an event

1

Some app activity occurs

Your database is your source of truth. When some key action occurs in your app, it’s reflected as a change to a row in your database.
2

Trigger executes

When that row changes, a database trigger is executed that logs a row in the dreamlit.event_log table. It’s fully managed by Dreamlit, and runs asynchronously after the row changes in a separate non-blocking transaction. It has a negligible impact on database performance.
3

Dreamlit picks up event

Dreamlit tracks your dreamlit.event_log table for new events. When a new event is recorded in this table, Dreamlit detects it within seconds and idempotently kicks off any associated workflow.If you have a lot of events and you’d like to clean up event data, you can periodically truncate the table to prune old events.
4

Workflow executes

Each step in your workflow is run in a robust, durable manner. For any wait steps, we handle the scheduling for you. If any steps fail, we automatically retry with exponential back-off.For hard failures, we escalate to you. Any failed runs can be re-run manually in the Dreamlit dashboard.
5

Notifications are delivered

For any notification steps, templates are populated, and the final notification(s) are sent to the appropriate recipient or channel.If a workflow is sandboxed, then they’re held for manual review and release in the Dreamlit dashboard.
6

Engagement events are captured

Dreamlit handles capturing analytics on the notifications sent, including delivery status and engagement metrics.