Start here
When not to use it
A docs site that only lists its own strengths is worth nothing to the person reading it. Here is the list we would want if the positions were reversed.
Use native logical replication instead when
- You have one source and one target, both reliably online.
- One team owns the schema on both ends.
- Nobody has ever asked you to prove a destination converged.
- You are already comfortable operating slots and would notice a stalled one.
Native replication keeps getting better — failover slots, parallel apply, idle-slot timeouts, sequence sync. None of that closes the three gaps Trellara exists for, but if you are not feeling those gaps, the extra component is a cost with no return.
Use something else when
| If you need | Look at |
|---|---|
| Sources other than PostgreSQL | Debezium, Striim, or a managed ELT vendor. Trellara has no Oracle, SQL Server, MySQL or MongoDB support, and none is planned until the Postgres wedge is proven. |
| Transformation, enrichment or joins in flight | An ELT platform. Trellara reshapes nothing between source and destination by design. |
| Connector breadth to many destinations | Debezium plus Kafka Connect. Its connector ecosystem is the thing it is best at. |
| Rows in a warehouse with minimal operational effort | Fivetran, Airbyte or Estuary. If the warehouse is the point and completeness is not contested, managed ingestion is a better trade. |
| Multi-master writes across regions | pgEdge. Trellara is single-writer by design and has no conflict resolution. |
| A vendor with a signed uptime commitment | Any commercial vendor on that list. This is a real reason to choose someone else and we will not argue with it. |
What Trellara does not have
No managed cloud, no support SLA, no SOC 2, and no third-party correctness audit. No tagged release, so there is nothing to pin a dependency to. Release binaries carry SHA-256 checksums but are not signed, have no SBOM, and have no build-provenance attestation.
Recovery is proven correct in 63 deterministic scenarios and has never been timed. There has been no soak run. The optional native extension has a live CI lane across PostgreSQL 15, 16, 17 and 18 — each job installs it on a real server and runs a crash and acknowledgement suite. The external relay, which is the default path, has no CI Postgres lane at all: its integration tests are environment-gated and only PostgreSQL 16 has been exercised end to end, by hand. Treat that as the version we have run, not as a support matrix.
The full itemised version, with what is established beside it, is the evidence table. The competitive version, with sources, is the comparison page.
Where the product is narrower than the story
- The lakehouse writer. Append-only raw changelog, Iceberg REST catalog, S3-compatible storage. No native equality or position deletes, and no native current-state or SCD2 mutation — those are Spark templates you run yourself.
- The fleet runtime. Fleet configuration, reporting and scorecards ship. A continuously running multi-source fleet control loop does not yet.
- The command surface. There are far more commands than a first-time reader should have to meet. Collapsing that to one legible path is active work.
- Tenant-boundary attestation. Specified in the design docs and not built. Price it at zero.