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

# For developers

> Why engineering teams use Dreamlit for database-driven email notifications. No SDK, no API calls, and no notification code to maintain in your app.

Let's be honest: notifications are usually the last thing engineers want to work on. Between templates, scheduling, retries, and monitoring, they eat the hours that should go into the product.

## Why should developers use Dreamlit for notifications?

Dreamlit replaces the notification plumbing you'd otherwise build in your app. There's no SDK to learn, no API calls to add, and no events to emit. Your app writes to the database as usual, and Dreamlit reacts to those changes to send notifications.

* **No SDK**: nothing to import, pin, or upgrade
* **No API calls**: no Twilio, SendGrid, Mailgun, or Resend wiring in your backend
* **No event emission**: your app doesn't need to "know" that notifications exist
* **No infrastructure to maintain**: queues, retries, scheduling, rate limiting, and analytics are handled end-to-end

This works because of Dreamlit's [database-driven architecture](/docs/getting-started/how-it-works). Your database is already the source of truth for app state, which makes it the best signal for what should trigger a notification.

## Why does coupling notifications with app code cause problems?

Adding notifications directly to your backend looks simple at first. At scale, it becomes a source of latency, bugs, and on-call pages. Here's how the traditional approach stacks up against Dreamlit.

| Concern                      | Traditional (in-app + API)                                                        | Dreamlit (database-driven)                                     |
| ---------------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| **Scaling under load**       | You build queues, retries, rate limiting, and fan-out yourself                    | Durable, distributed execution built in                        |
| **Email templates**          | Hand-coded HTML, separate preview setup, test-to-self loops                       | AI-generated, responsive templates previewed against live data |
| **Third-party coordination** | Type-unsafe events, template drift, contact sync jobs                             | Schema is the contract. No sync layer required                 |
| **Hot-path risk**            | Notification logic adds latency and failure modes to business-critical code paths | Notifications run outside your app's request path              |

The longer your product runs, the more these tradeoffs compound. A cron job with one API call today becomes a three-week cleanup next quarter.

## How does Dreamlit save engineering time?

Dreamlit gives you end-to-end notification infrastructure in minutes instead of days. For most teams, that's weeks of engineering time recaptured every year.

<Steps>
  <Step title="Generate workflows from plain English" icon="robot">
    Describe a workflow in plain English, and the Workflow Agent generates the trigger logic, timing, and templates. Drop into the details whenever you need to, and use the testing agent to validate the workflow end-to-end before you publish.
  </Step>

  <Step title="Hand off lifecycle emails to your product team" icon="users">
    Once the plumbing is in place, your PMs and marketers can own lifecycle emails without pulling you into every change. Engineering unblocks product without becoming a permanent support queue.
  </Step>

  <Step title="Inherit production-grade infrastructure" icon="expand">
    Every published workflow runs on a durable, distributed backbone:

    * **Retries with exponential backoff** for transient failures
    * **Managed scheduling** so you never write another cron job
    * **Rate limiting** to protect your database and downstream services
    * **Fan-out parallelization** for high-volume triggers
    * **Engagement tracking** (opens, clicks, deliverability) logged automatically, with <Tooltip tip="Coming soon">delivery events streamed back into your own database</Tooltip>
    * **Multi-channel delivery** across email and Slack
  </Step>
</Steps>

## How do you handle database schema changes safely?

Dreamlit workflows reference table and column names, so renames or removals can break a published workflow. You have two strategies, both documented in the [Supabase configuration guide](/docs/configuration/data-sources/supabase#making-schema-changes-safely).

* **Unpublish, change, republish**: the fastest path if brief workflow downtime is acceptable. Unpublish the affected workflow, apply the migration, adjust the workflow steps to reference the new schema, then publish again.
* **Expand, migrate, contract**: a zero-downtime pattern borrowed from [backward-compatible database changes](https://planetscale.com/blog/backward-compatible-databases-changes#the-expand-migrate-and-contract-pattern). Add the new columns, dual-write from your app, backfill historical rows, cut Dreamlit over to the new references, then remove the old columns.

Either way, Dreamlit surfaces broken references in the dashboard, so you catch issues before your users do.

## Explore further

<CardGroup cols={4}>
  <Card title="Workflow basics" icon="diagram-project" href="/docs/workflow/basics">
    Learn how workflows are built.
  </Card>

  <Card title="How it works" icon="gears" href="/docs/getting-started/how-it-works">
    Learn about the architecture.
  </Card>

  <Card title="Quick start" icon="rocket" href="/docs/getting-started/quickstart">
    Create your first workflow.
  </Card>

  <Card title="Security" icon="shield" href="/docs/resources/security">
    Security is our top priority.
  </Card>
</CardGroup>

## References

* [Database-driven architecture overview](/docs/getting-started/how-it-works)
* [Supabase configuration: making schema changes safely](/docs/configuration/data-sources/supabase#making-schema-changes-safely)
* [Expand, migrate, and contract pattern (PlanetScale)](https://planetscale.com/blog/backward-compatible-databases-changes#the-expand-migrate-and-contract-pattern)

***

Last validated: 2026-04-20