PostgreSQL

Notika integrates seamlessly with your PostgreSQL database, allowing you to trigger notification workflows based on row changes (inserts/updates).

​

Adding a connection

Notika requires an IPv4 compatible connection to your database. To ensure optimal performance, we strongly recommend using a connection pooler like Pgbouncer in transaction mode and connecting through that instead of directly to your database.

To add a connection:

1. Go to Settings → Database Connections.
2. Click + Add connection.
3. Paste your PostgreSQL URL (e.g., postgresql://user:password@host:5432/database) into any field. Notika will automatically parse and fill in the required fields.
4. Verify all details, and configure SSL settings if necessary.
5. Click Test Connection to ensure it works before saving.
6. Click Save.

​

How Notika configures your database

Notika’s notification architecture is optimized for the performance and robustness of your workflows. Your database is minimally instrumented accordingly.

The very first time you set up a database connection, Notika creates a notika schema (if it doesn’t already exist) and an event_log table inside it. Then, whenever you publish a workflow containing a Database Trigger step, Notika creates:

1. A table trigger on the specified table, which activates whenever a relevant insert or update occurs.
2. A trigger function in the notika schema that runs when the trigger fires, which simply logs a row to the notika.event_log table indicating that a new event has occurred.

From there, Notika efficiently monitors the notika.event_log table, and whenever it sees a new row matching an active trigger, it launches the associated workflow.

​

Permissions needed

The Postgres user provided to Notika must at least have the following permissions:

• Read relevant tables (SELECT).
• Create triggers on tables that launch workflows.
• Manage its own notika schema for housekeeping and logging.

Of course, if you already have a user with the sufficient privileges (such as a superuser) you can use that.

However, it is best practice to create a separate Postgres user for each service that needs access to your database, following the principles of isolation and least privilege.

As such, we recommend following the steps below to create a dedicated user with the minimum permissions required for Notika.

​

Protecting notifications from breaking schema changes

When you make database schema changes, such as renaming or dropping tables or columns, you risk accidentally breaking notifications linked to your Notika workflows.

To help you avoid silently breaking notifications, Notika provides two protective options:

​

Making the schema change safely

To ensure a smooth transition to a new schema for an otherwise breaking change, we recommend one of the following approaches:

​

Uninstalling Notika

If you ever want to remove Notika entirely:

1. Unpublish all workflows that depend on your Postgres connection (this removes triggers/functions).
2. Delete the connection in the Notika dashboard.
3. (Optional) Drop the notika schema to remove all Notika-managed objects.