Postgres read replica vs. warehouse: an honest decision guide

The question we get most often from technical founders is some version of “do we actually need a data warehouse?” It’s a hard question to get a straight answer to, because almost everyone you can ask is selling the yes: warehouse vendors, BI vendors, the data engineer you’re interviewing. So here is the framework we actually use, with our incentives declared up front — sometimes the honest answer pays us nothing.

Stay on the replica when

A read replica of your application Postgres gets analytics load off production for close to nothing — many managed hosts bundle one, and otherwise it’s tens of dollars a month. Free-ish, next to any warehouse line item. It’s the correct stack when three things are true at once:

• Your data fits. Postgres is comfortable well into the hundreds of gigabytes with sane indexes, and most companies before Series B are nowhere near that.
• Your questions are simple and single-source. Counts, sums, and group-bys over your own tables: signups by week, revenue by plan, usage by account.
• Your sources are basically your app database. The business runs through your product, plus maybe a Stripe sync you already maintain.

Point a lightweight BI tool at the replica, write SQL, and get back to shipping. There is no maturity prize for owning a warehouse.

The four real signals you’ve outgrown it

• Cross-source joins. The questions that matter now span systems: which marketing channel produces customers who retain requires product, billing, and ad-platform data in one queryable engine. The tell is someone hand-joining CSV exports in a spreadsheet every month — that’s a warehouse job being done by a person.
• Analytics is hurting production. The dashboard query that takes 40 seconds, bloats replication lag, and makes on-call nervous. Tuning one database for both transactional and analytical work means doing both badly.
• History has outgrown row-store scans. Two years of event data is where a row store starts scanning for minutes on questions a columnar engine answers in seconds. The damage is silent: analysts stop asking historical questions because they’re slow, and decisions quietly get worse.
• You need reproducible metric definitions. Saved queries in a BI tool drift; nobody reviews them, and last quarter’s “activation” isn’t this quarter’s. The moment an investor or enterprise customer asks for a metric you can reproduce across quarters, you need version-controlled models — which is really an argument for a modeling layer, and the engine that makes one practical.

The middle path vendors skip

When the signals do show up, a full warehouse platform is not the only next step. Our default middle path: DuckDB over Parquet files in object storage. Scheduled exports from Postgres plus managed connectors for the SaaS sources land in a bucket; dbt models on top give you the version-controlled definitions; Postgres stays the source of truth for the application, untouched. You get columnar speed, cross-source joins, and tested metrics for roughly $100–300 a month of compute and storage, instead of a four-to-five-figure monthly platform commitment. A single node scanning tens of gigabytes in seconds sounds modest until you notice that, at startup scale, tens of gigabytes is your entire history.

The migration nobody scopes

Whichever direction you go, the trap is the same: everyone budgets the infrastructure and nobody budgets the semantics. Standing up the engine and the connectors is a weekend or two. The actual project is that every dashboard and saved query you’re replacing encodes a metric definition — usually an unwritten one — that has to be re-derived and then reconciled against the old numbers. And the first run won’t match. Timezone handling differs, refunds are treated differently, a join fans out somewhere, and revenue is suddenly 3% higher in the new system than the old one. If you ship without reconciling, you now have two systems that disagree, and trust in the numbers drops at the precise moment you spent money to raise it. The failure pattern is a migration declared done in three weeks, followed by six months of “which number is right.” Scope the reconciliation, not the connectors — it’s 80% of the work and all of the value.

The honest bottom line: most seed-stage companies should stay on the read replica longer than the vendors tell them. Move when the four signals above show up repeatedly — not once, and not because a sales deck implied that real companies have warehouses.

We build both ends of this — the boring replica-plus-SQL setup and the DuckDB-and-dbt stack when it’s earned — and run them on retainer, reconciliation included. When a prospect only needs the replica, that’s the advice they get.