Most of the time, you should not use Trellara.

What core already does well — and it is more every year

Any comparison written against PostgreSQL 14 is dishonest by now. The recent releases have moved directly at the pain CDC vendors used to market against:

What it still leaves to you

1. DDL is not replicated. Schema changes are yours to coordinate by hand, in the right order, across every subscriber. Get it wrong and apply errors until a human intervenes. There is no propagation contract, no per-sink acknowledgement, and no visibility barrier holding back post-DDL rows until the targets have accepted the new schema version.

2. Consumer health is still coupled to your primary's disk. idle_replication_slot_timeout reaps slots nobody is using. It does not help with the more common and more dangerous case: a slot that is connected and slow, or connected and stuck on a bad record. That slot retains WAL for as long as it takes. Your two protections are a storage alarm and max_slot_wal_keep_size — and the second one protects the primary by invalidating the slot, which means a full resync of that subscriber. Core's honest offer is: risk the primary, or lose the destination. Trellara's answer is to acknowledge the source only after a publish is durable in a log you control, so the pressure sits on a disk you sized for it.

3. Nothing verifies convergence. Postgres will tell you a subscription is streaming and how far behind it is. It will not tell you the two sides hold the same rows. Confirming that is a row-count and checksum job you write yourself, per table, per environment, and then maintain. Every team we have talked to either wrote one or decided not to look.

4. Bad data stops the subscription. The recovery model is disable_on_error plus skipping a transaction by hand with pg_replication_origin_advance — in production, under pressure, with no record of what was skipped. There is no quarantine, no replay-ready artifact, and nothing keeping an unrelated flow moving while you decide.

5. There is no fleet object. Fifty databases means fifty publications, fifty slots, fifty subscriptions and fifty pieces of state, with no way to ask a question about all of them at once. This is the gap that grows fastest with your business, and it is the one core is least likely to close, because it is an operations product rather than a database feature.

6. Reseed is manual, and offline nodes are expensive. A node past retention means drop, re-copy, re-hand-off, by hand. A store that goes dark for a day pins a day of WAL on the source for a day.

7. There is no analytical destination. Logical replication replicates to PostgreSQL. Getting the same committed transactions into Iceberg is a separate product, separate slot, and separate correctness argument.

The specific question to ask on a Striim evaluation

Not “what is your latency” — both answers will be fine. Ask: “after a broker restart and an applier crash during a multi-table transaction, what command proves to my auditor that the target holds exactly what the source committed?” That separates a monitoring answer from a verification answer.

The fair question back at us: “what happens when the third source turns out to be Oracle?” Call Striim.

The divergence shows up in three places. Direction: they move source → warehouse; they do not apply back into an operational PostgreSQL target atomically. Scale shape: connector-per-source pricing and configuration is comfortable at ten sources and untenable at a thousand — this is the specific reason we scoped the second pillar as fleet fan-in rather than single-source ingestion, where the market is already commoditised. Completeness: they will tell you a sync succeeded. They will not tell you which of your two thousand stores are represented in last night's table, through which commit LSN.

Worth noting honestly: Airbyte's own documentation warns that if max_slot_wal_keep_size is exceeded PostgreSQL can invalidate the slot and force a full resync — which is a fair and public statement of the exact problem our first command exists to detect early.

Where that trade stops being obvious: data residency and cloud choice, where your object storage and catalog have to stay yours; the Postgres you already run, which an integrated platform would rather replace; and coupling — an integrated stack ties your operational database's fate to a lakehouse vendor's roadmap. Trellara lands standard Parquet in your object storage under your catalog, readable by Spark, Trino, DuckDB or anything else.

There is a structural reason we lead with the licence. Every independent PostgreSQL change-movement company so far has been absorbed by a destination platform: PeerDB into ClickHouse, Mooncake and Neon into Databricks, Sequin acquired with its cloud shut down in October 2025. The layer underneath consolidated too — IBM closed its $11bn acquisition of Confluent in March 2026, and already owned Debezium through Red Hat. Apache-2.0 with an open protobuf wire schema and a documented on-disk format is not marketing; it is the only structural answer to that pattern that survives an acquisition of us.