Trignis

Trignis watches your database tables and tells something else when they change. Point it at SQL Server or PostgreSQL, say which objects to track and where changes should go, and it keeps sending them to a file, an HTTP endpoint, or a message queue.

Useful for data synchronization, audit trails, ETL processes, and application integration scenarios where you need to track and propagate database changes reliably.

Trignis polls on a timer rather than firing on every write. That is intential. In some cases, the same record may be updated up to 50 times before the final commit. If you're looking for a direct or real-time mechanism, please consider implementing it programmatically through a SDK or using alternative extension methods.

Requirements

• .NET 10+ Runtime
• Microsoft SQL Server, or PostgreSQL 13+

Caution

Whichever mechanism you pick accumulates data that has to be cleaned up: SQL Server change tracking has side tables, a PostgreSQL outbox has its own table. Read Risks before enabling either on a production database.

Getting started

Docker

Configure environments/ and appsettings.json, then start the container. The setup script does both:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/melosso/trignis/refs/heads/main/docker-setup.sh)"

Prefer to do it by hand? Start from the included docker-compose.yml.

Windows

Download the latest release and extract it to your deployment folder.

Trignis encrypts its own configuration, so it needs a key before first run. On Windows, store it as a machine environment variable:

$bytes = New-Object byte[] 48; [Security.Cryptography.RandomNumberGenerator]::Create().GetBytes($bytes); [Environment]::SetEnvironmentVariable("TRIGNIS_ENCRYPTION_KEY", [Convert]::ToBase64String($bytes), "Machine")

In containers, set TRIGNIS_ENCRYPTION_KEY the same way. Lose this key and the encrypted configuration cannot be recovered. You would have to delete .core/ and re-enter every secret.

Point it at a database

Each file in environments/ is one self-contained environment, with its own connection strings, tracked objects and destinations:

{
  "ConnectionStrings": {
    "PrimaryDatabase": "Server=prod-sql.company.com;Database=PrimaryDB;Trusted_Connection=True;"
  },
  "ChangeTracking": {
    "ExportToFile": true,
    "TrackingObjects": [
      {
        "Name": "Orders",
        "Database": "PrimaryDatabase",
        "TableName": "dbo.Orders",
        "StoredProcedureName": "dbo.sp_GetOrderChanges"
      }
    ]
  }
}

Drop a file in and Trignis picks it up without a restart. Start the service, then browse to http://localhost:2455 for the dashboard.

Changes are read through a stored procedure you write, which keeps the shape of the payload under your control. That procedure has to return a specific JSON structure. See the Reference for the contract and a working example.

Risks

Capturing changes is never free, and the bill differs per database.

SQL Server change tracking. Expect roughly 5–10% slower writes on tracked tables, since every change is recorded. The side tables grow and need regular cleanup. SQL Server 2025 (17.x) and later switched to an adaptive shallow cleanup for large side tables, which behaves differently from the deep cleanup in earlier versions. sp_flush_CT_internal_table_on_demand still has to be run manually. Trignis does not do it for you. See About Change Tracking and KB3173157. Compatibility with older SQL Server versions is not guaranteed.

PostgreSQL outbox tables. A row trigger runs inside every write, so the cost lands on the writing transaction. The outbox grows until you trim it, and Trignis cannot trim it for you — it does not know which consumer is furthest behind. Trim below the watermark shown on the dashboard, never above it. Long-running transactions hold the visibility horizon back, so changes arrive late and in bursts rather than being lost.

Neither is mandatory. Any column that only increases and is assigned no earlier than commit will do, on either platform.

Failed exports go to a dead letter store (sinkhole.db) rather than being retried forever. Trignis retries them on a widening backoff, five times by default, then leaves them for you to replay or discard from the dashboard.

Tip

Brent Ozar's Performance Tuning SQL Server Change Tracking is worth reading before committing to the SQL Server route.

Lore

Trignis blends trigger with ignis; Latin for fire, or spark. A trigger sets automation in motion, ignis is the moment it catches. Trignis meddles in exactly that moment.

License

Licensed under the EUPL 1.2. See the license file for details.

Contributing

Contributions are welcome. Please use the issue and pull request templates.