Migrate from Fivetran to Bruin: cut Postgres-to-BigQuery costs

Quick answer: if a PostgreSQL-to-BigQuery Fivetran connector is processing 20 million billable monthly active rows (MAR) each month, a rough $1,500 monthly bill is a reasonable migration trigger. With Bruin and ingestr, the software cost can be $0 when you run the open-source tools locally or in your own CI. A small self-managed server adds only its infrastructure cost, while a lightweight Bruin Cloud workload can stay below $100 a month when its actual memory-hour usage stays small.

That is not a promise that every 20 million-row database will cost exactly the same. Fivetran bills connections by MAR: distinct source records inserted, updated, or deleted during a calendar month. Twenty million rows sitting in PostgreSQL is not automatically 20 million MAR. Neither is a row that changes ten times in the same month, which Fivetran counts once for MAR. Check Fivetran's current pricing documentation and your account's estimator before treating any number here as a quote.

But the direction is clear. If the workload is a straightforward database replication job, you do not necessarily need a per-row managed connector bill to move it reliably.

The Postgres-to-BigQuery example

Here is the deliberately simple scenario behind this guide:

The cost comparison is about the ingestion layer. Your existing BigQuery storage and query costs still exist. So do the PostgreSQL resources and network path needed to read the source. Bruin does not make those disappear. It removes the managed connector's MAR charge and lets you decide where the pipeline runs.

The last row deserves some care. Bruin Cloud includes a default $100 free credit and 10 memory hours. That makes sub-$100 execution plausible for a small batch workload, but you should run a representative week, inspect the memory-hour usage, and extrapolate before promising a monthly number internally. The cost is tied to how the pipeline runs, not to the number of source rows alone.

Why teams migrate away from Fivetran

The obvious answer is cost. It is still not the only one.

MAR grows with the business

When the database gains customers, events, orders, or frequent updates, a MAR-priced connector grows with it. That can be a fair trade when you want a vendor to own the connector, but it also means a simple replication workload becomes more expensive just because your product is doing well.

For a Postgres table with a stable primary key and a sensible updated_at field, the move is often not technically mysterious. You need an incremental load strategy, a destination write strategy, checks, and a cutover plan. That is a proper data-engineering task, but it is not a reason to accept an open-ended per-row bill by default.

The pipeline can live in your repository

Fivetran work often begins in a product UI, even when teams later automate setup. A Bruin migration gives you versioned assets, a reviewable pipeline.yml, SQL or Python transformations next to ingestion, and checks that explain what "healthy" means. It is easier to answer questions such as:

• Which source table feeds this BigQuery table?
• Which primary key and watermark drive the incremental load?
• Who owns the asset?
• What happens if the row count falls to zero?
• What did we change before the numbers moved?

In a Bruin project, you can keep those decisions beside the ingestion asset instead of scattering them across a connector UI, a transformation repo, a scheduler, and a monitoring tool.

You can choose the operating model

The open-source path is useful when private connectivity, VPC deployment, on-prem infrastructure, or a read replica is part of the architecture. You can run Bruin locally, in CI, on a server, or with an existing orchestrator. Bruin Cloud is the managed option when you want schedules, run history, lineage, secure connections, and usage monitoring without operating the server yourself.

Do not replace every Fivetran connector by reflex. A rare SaaS connector with tricky source behaviour may still be worth paying Fivetran for. Start with the high-volume database connector whose behaviour you understand, prove the path, then decide what belongs in the new stack.

How the out-of-the-box Fivetran migration flow works

The Fivetran-to-Bruin Academy guide is designed for a staged migration, not a one-shot rewrite. It gives an MCP-enabled coding agent a migration prompt and a local skill that imports one selected Fivetran connector with read-only API requests.

1. Create the migration project

Start from a clean directory:

bruin init migration-fivetran fivetran-to-bruin
cd fivetran-to-bruin

The template gives you a migration plan, the coding-agent prompt, and .agents/skills/bruin-fivetran-migrator/. The skill imports a selected connector configuration, writes a redacted capture to .artifacts/, and leaves the decisions in plan.md. Keep the repository-root .bruin.yml and imported artifacts out of Git because that is where your connection configuration and local secrets live.

2. Give the agent Bruin MCP access

Bruin MCP lets the agent read current documentation and work with project-aware CLI commands. For Codex, the CLI configuration is:

[mcp_servers.bruin]
command = "bruin"
args = ["mcp"]

The full Bruin MCP setup guide covers other coding agents too. The server command is only bruin mcp; credentials belong in the migration project's local connection configuration, never in an agent chat or MCP config file.

3. Start the migration agent with the supplied prompt

Open a new agent chat from the migration project root and send exactly this:

Read @fivetran-bruin-prompt.md and execute that prompt. The connections are already configured in the root .bruin.yml.

The agent should read plan.md, import one Fivetran connector, and stop for decisions it cannot safely infer. It should not disable Fivetran, enable a production schedule, or write into a production table just because it can see a connector configuration.

For this PostgreSQL-to-BigQuery example, give the agent a concrete scope:

4. Review the ingestr asset before it writes data

For a normal incremental table, the draft will look roughly like this. The final version should use the table name, keys, columns, and destination mapping you approved.

name: migration_v0.orders
type: ingestr
connection: analytics_bigquery
materialization:
  type: table
  strategy: merge
  incremental_key: updated_at
parameters:
  source_connection: production_postgres
  source_table: public.orders
  destination: bigquery
columns:
  - name: id
    type: integer
    primary_key: true
  - name: updated_at
    type: timestamp

Bruin supports ingestr as a native asset type. Its ingestr asset reference documents the supported destination strategies, connection resolution, schema contracts, and Postgres CDC options. merge needs a primary key, and the incremental key needs to match the source's real change semantics. If updated_at is unreliable, fix that design decision before the migration rather than hoping the tool guesses correctly.

5. Validate in parallel, then cut over

The important part of a Fivetran migration is not writing the first table. It is proving the new table is safe to consume.

Run the initial load into the isolated schema. Then compare:

• Row counts and daily counts by a stable business dimension
• Primary-key uniqueness and null rates
• Source and destination freshness
• The full incremental range, including late-arriving data
• Important business aggregates such as order totals or customer counts
• Schema and column statistics with bruin data-diff --full where the two tables are comparable

bruin data-diff compares schemas by default and can add row counts and column statistics with --full. It is useful evidence, not a substitute for the business-level parity checks you agree with the data owner.

Keep Fivetran live while the new path writes to migration_v0. Switch one downstream consumer only after the new output matches or intentionally corrects the old output. Keep a rollback window. Then, and only then, disable the Fivetran connector or redirect consumers to the final Bruin table.

Bruin vs ingestr vs Fivetran

These are not three identical products. Ingestr is the open-source ingestion engine. Bruin uses it natively and adds the broader pipeline workflow. Fivetran is the managed connector service.

The practical choice is usually simpler than the product categories make it sound:

• Use Fivetran for a connector you do not want to own or a source whose operational edge cases outweigh the price.
• Use ingestr alone when the job really is just "move this data here" and you already have a good scheduler and observability setup.
• Use Bruin when the ingestion job should be part of a governed pipeline with transformations, tests, lineage, schedules, and an agent-readable project.

For a Postgres-to-BigQuery database connector, the last two are often the cheap Fivetran alternative. Bruin does not replace ingestr in that setup. It gives ingestr a pipeline home.

FAQ & quick answers

Is Bruin a Fivetran alternative?

Yes, for teams that want to migrate a managed connector into an open-source, code-first pipeline. Bruin is broader than ingestion: it uses ingestr for the load, then adds SQL and Python assets, checks, lineage, and orchestration. Validate connector behaviour before you call it a one-for-one substitute for every SaaS source.

What does 20 million rows per month cost in Fivetran?

The example here models 20 million billable MAR as roughly $1,500 per month. That is not a public rate card calculation. Fivetran charges based on distinct records inserted, updated, or deleted, and pricing varies by plan, contract, connection layout, and usage. Use the current Fivetran pricing estimator for the number that matters to your account.

Can I migrate PostgreSQL to BigQuery with Bruin?

Yes. Configure a Postgres source connection and a BigQuery destination connection, have the migration flow draft an ingestr asset, then review its primary key, incremental key, write strategy, schema contract, and target before the first load. Start in an isolated destination schema.

Is ingestr the same as Bruin?

No. ingestr is an open-source data ingestion tool. Bruin uses it for native ingestion assets and adds the pipeline layer around it. You can run ingestr by itself for a focused CLI job or use it inside a Bruin project when the load needs transformations, checks, lineage, and managed operations.

How do I migrate away from Fivetran without downtime?

Do not replace the production destination immediately. Run Fivetran and Bruin in parallel, write the first Bruin load to an isolated schema, compare output and freshness, switch one consumer at a time, and retain a rollback path. The Academy migration guide walks through the prompt, review gates, and v0 approval flow.

Is Bruin Cloud always under $100 per month?

No. The sub-$100 figure is a reasonable budget for a lightweight workload, not a fixed plan price. Bruin Cloud tracks execution by memory hours, so measure a representative run and base your budget on actual usage.

If the only problem is an expensive Postgres connector, start there. Build the parallel path, prove it, and keep the rest of the stack unchanged until there is a reason to move it too. That is how you reduce Fivetran costs without turning a connector migration into a platform rewrite.