PostgreSQL

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

​

Adding a connection

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.

Below is a guide to create a dedicated user with the minimum permissions required for Notika. Run these SQL commands in your database:

​

1. Create a dedicated Notika user

First, we create a new database user specifically for Notika with a secure password. Be sure to replace <SECRET_PASSWORD> below with a strong, unique password.

CREATE USER notika_user WITH PASSWORD '<SECRET_PASSWORD>';

​

2. Grant ability to create and manage the notika schema

Next, we allow the Notika user to create and manage the notika schema within your database. Be sure to replace <YOUR_DATABASE_NAME> below with the name of your database (e.g., defaultdb or postgres).

GRANT CREATE ON DATABASE <YOUR_DATABASE_NAME> TO notika_user;

-- if `notika` schema already exists (like if you already setup a Notika connection previously to the database with a different user), you need to run the following:   
GRANT notika_user TO <OLD_OWNER_USER_NAME>; -- needed to run the commands below. This grants membership of the old owner (for ex, "postgres" user) of `notika` schema objects to notika_user.
ALTER SCHEMA notika OWNER TO notika_user;
ALTER TABLE notika.event_log OWNER TO notika_user;
ALTER TABLE notika.version OWNER TO notika_user;

​

3. Grant view access and trigger creation permissions

Finally, we need to ensure the Notika user has view and trigger creation access to the tables you’d like to build workflows on.

Run the commands below for each schema, replacing <YOUR_SCHEMA_NAME> with each schema name (e.g., public).

GRANT USAGE, CREATE ON SCHEMA <YOUR_SCHEMA_NAME> TO notika_user;
GRANT SELECT, TRIGGER ON ALL TABLES IN SCHEMA <YOUR_SCHEMA_NAME> TO notika_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA <YOUR_SCHEMA_NAME> GRANT SELECT ON TABLES TO notika_user; -- ensures future tables created will be readable for this user by default

If any of your tables have RLS enabled (common for Supabase projects if you use the “anon” role), you must create policies that allow the newly created notika_user to SELECT rows. Otherwise, you won’t be able to read the data needed for your Notika workflows.

If you’re not sure, you can run the following command to check which tables have RLS enabled:

-- First, check which tables have RLS enabled
SELECT schemaname, tablename, rowsecurity 
FROM pg_tables 
WHERE schemaname = '<YOUR_SCHEMA_NAME>' AND rowsecurity = true;

If the above query returns any rows, then you have RLS enabled and you’ll need to create a policy for each table that allows the notika_user to SELECT rows.

Run the following command to generate the policy creation commands for all RLS-enabled tables:

-- Generate CREATE POLICY commands for all RLS-enabled tables
SELECT 'CREATE POLICY notika_user_select_policy ON ' || schemaname || '.' || tablename || 
      ' FOR SELECT TO notika_user USING (true);' as policy_command
FROM pg_tables 
WHERE schemaname = '<YOUR_SCHEMA_NAME>' AND rowsecurity = true;

Finally, copy and execute the commands returned from the above query.

For future tables: Unfortunately, PostgreSQL doesn’t support default RLS policies like it does for privileges. You’ll need to remember to create a policy whenever you add a new table with RLS enabled.

​

4. Construct your new connection string

Construct your PostgreSQL connection string using the notika_user and the <SECRET_PASSWORD> you created. Provide this string to Notika.

Copy the correctly formatted connection string and paste it into the Notika connection setup field.

​

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.