Hosted by us · or in your VPC
Your data in the
lakehouse. Not your
team on pipelines.
Fabric continuously replicates PostgreSQL, MySQL, SQL Server, MariaDB, MongoDB, IBM Db2, or Zoho CRM into Iceberg, Delta Lake, Postgres, S3 Tables, Snowflake, or ClickHouse. No Kafka, table maintenance built in — hosted by us, or in your own VPC. Spend your engineers on analytics, not infrastructure.
- Sources
- 24
- Sinks
- 25
- Freshness
- 30s
- Install
- 1 chart
Why Fabric
Change data capture without the platform team
Most CDC stacks make you assemble the pipeline and then keep it alive. Fabric ships the whole path, from source log to a maintained table, as one product — run it yourself, or let us run it for you.
One pipeline, any destination
Choosing a table format is a setting, not a re-platform. Point an existing source at a new destination and everything downstream of the write — batching, checkpoints, and quarantine — works the way it already did, behind one writer contract.
A pipeline that runs itself
Compaction, snapshot expiry, and orphan-file cleanup are part of Fabric, on a per-source schedule you set once. Schema drift is handled the same way: new columns land nullable and flow through without a restart (a MySQL change across a restart needs a reset), and a drifted schema is refused rather than silently decoded wrong. No Kafka, no schema registry, no Spark or Trino job to babysit.
Your data stays yours
Self-hosted: one Helm chart into a Kubernetes cluster in your own VPC, running in a day — credentials and every row of change data stay inside your network, on storage you own. Hosted: the loader holds credentials encrypted and the row data in memory only until the commit. Either way the tables land in the lakehouse you own.
Capabilities
The depth behind the headline
What Fabric does on the data plane: schema evolution, per-table backfills, and low-latency commits that stay safe.
Full schema evolution
Additive-only on every sink: new columns land nullable, source types are never retyped, and a live source ADD COLUMN flows through without a restart. A MySQL schema change made while the runner was down refuses to resume until you re-snapshot or reset. Your schema keeps moving; the pipeline keeps up.
Per-table re-snapshot
Re-snapshot a single table (corrupt data or a changed transform) without resetting the source. The replication cursor, slot, and every other table stay untouched.
Incremental new-table load
Add tables to a running source and only those new tables snapshot, under a fresh engine mark, before CDC resumes.
Schema-guard on restart
If a source's schema drifts across a restart, Fabric refuses to resume a stale decode and tells you to re-snapshot; it never silently corrupts.
30-second freshness
Commits every 30 seconds by default, well below the multi-minute freshness floors common in CDC tooling.
Automated maintenance
Small-file compaction, snapshot expiry, and orphan-file cleanup on a per-source schedule. Set the policy once, and the table stays lean without a separate maintenance job.
01 ✳ Schema drift
Schema drift lands mid-stream, and live DDL needs no restart
A live source ADD COLUMN is detected on the next batch and added nullable on every sink. Fabric keeps streaming through it; a MySQL change made while the runner was down refuses to resume until you re-snapshot or reset. Nothing else in the pipeline has to know it happened.
$ tail -f fabric.log
12:04:02 ALTER TABLE orders ADD COLUMN discount_pct numeric
· detected on postgres_cdc source, mid-stream
· added nullable on iceberg.orders, no restart
✓ schema evolved · 0 restarts · 0 rows lost
02 ✳ Freshness
Sub-minute freshness, not an hourly batch window
Commits every 30 seconds by default, per source, well below the multi-minute-to-hourly floors common in batch ETL and most CDC tooling.
$ fabric freshness --compare
# commits every 30s by default, per source
03 ✳ Security & compliance
Column-level control, not a fixed rule list
Include, exclude, mask, hash, derive, or filter by row: it's a real Python function with pyarrow, run on every batch before the writer commits. Whatever a declarative include/exclude/encrypt/hash ruleset can express, this can too, plus cross-column logic and reshaping no fixed rule list covers. A failing script quarantines that batch; it never ships unprotected data.
Source table
| id | revenue | |
|---|---|---|
| 1 | jane@acme.com | $42,000 |
| 2 | bob@corp.net | $18,500 |
| 3 | sara@startup.io | $91,200 |
iceberg.orders
| id | revenue | |
|---|---|---|
| 1 | •••••••••• | $42,000 |
| 2 | •••••••••• | $18,500 |
| 3 | •••••••••• | $91,200 |
transforms/orders.py · runs every batch, before commit
Masked by FabricArchitecture
Zero infrastructure to run, because it's already yours
Self-hosted, one Helm chart reads your source's change log and writes straight to the sink you picked, inside the Kubernetes cluster and VPC you already run. No Kafka cluster, no schema registry, no separate maintenance job.
How it works
From operational database to maintained lakehouse
Fabric ships replication, automated maintenance, schema evolution and backfilling.
Point it at your source
PostgreSQL, MySQL, SQL Server, MariaDB, MongoDB, IBM Db2, or Zoho CRM: log-based CDC where the database supports it, polling-based for the SaaS sources that don't.
One write contract, every sink
The same connector/writer contract streams into every sink listed below. Pick your table format: you don't give one up to get another.
Maintenance runs itself
Compaction, snapshots, and table lifecycle are part of the product, not a downstream DBT/Trino job you have to build and babysit.
Sources
On the roadmap
Destinations
On the roadmap
Who it's for
Built for the team that has to own the pipeline
The two profiles where Fabric is the obvious answer today, not the everything-connector sale.
Data platform & infra teams at growth-stage companies
Series B–D-ish teams that already have a lakehouse, or are standing one up.
- The Fivetran/Streamkap bill is growing faster than data volume justifies, and someone has been told to own the pipeline.
- Security or compliance requires DB credentials and row data to never leave the company's VPC (finance, health-adjacent, anyone mid-SOC2) — the self-hosted chart is the one to run.
- You tried the Debezium + Kafka Connect + custom Iceberg-writer DIY path and are drowning in the ops surface.
Platform/DevOps teams evaluating a Postgres mirror
A narrower wedge, but a fast day-one win: no lakehouse decision required to get value.
- The PostgresWriter upsert-collapse sink as a read-replica-without-replication-lag-guarantees alternative.
- Get an operational Postgres mirror streaming today, add your lakehouse later.
Pay per running pipeline.
See pricingFAQ
The honest answers to the questions you're already asking
Get started
Streaming by end of day.
Sign up, point Fabric at your operational database, and pick where the tables land. No Kafka, no schema registry, no pipeline team to staff.
Product updates only, no spam.