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 hard to get a straight answer, 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 takes analytics load off production for the price of one more database instance. AWS describes the pattern plainly: route read queries to the replica to reduce load on the source database, and many managed hosts offer one as a checkbox. Next to any warehouse line item, it is close to free. It’s the correct stack when three things are true at once:

• Your data fits. In our experience Postgres stays comfortable into the hundreds of gigabytes with sensible 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. Knowing 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 fighting replication. A replica is not a free pass for long queries. The PostgreSQL docs explain that a hot standby must either delay applying changes or cancel conflicting queries, and that heavily updated tables “will quickly cause cancellation of longer running queries.” Turn on hot_standby_feedback to stop the cancellations and you trade them for possible table bloat on the primary. When the 40-second dashboard query keeps getting canceled, or keeps the on-call engineer nervous, one database is being asked to do two jobs.
• History has outgrown row-store scans. Postgres reads rows; analytical engines read columns. DuckDB’s own docs credit its columnar-vectorized execution for “far better performance in OLAP queries” than row-at-a-time systems like PostgreSQL. In practice, a couple of years of event data is where a scan that took seconds starts taking minutes. The damage is quiet: analysts stop asking historical questions because they’re slow, and decisions get worse without anyone noticing.
• 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. That is really an argument for a modeling layer, plus an 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 is DuckDB over Parquet files in object storage. Scheduled exports from Postgres plus connectors for the SaaS sources land in a bucket, and DuckDB reads and writes Parquet directly on S3-compatible storage. dbt models on top give you version-controlled definitions with built-in tests for uniqueness, nulls, accepted values, and relationships. Postgres stays the source of truth for the application, untouched.

The bill is small. Object storage such as Cloudflare R2 lists $0.015 per GB-month with no egress fees, so a few hundred gigabytes costs a few dollars. Add a small VM to run the jobs and the whole thing typically lands under $200 a month, against the four- or five-figure monthly commitments we see quoted for full platforms. 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.

The first run won’t match. Timezone handling differs, refunds are treated differently, a join fans out somewhere, and revenue is suddenly, say, 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 pattern we’ve seen most often is a migration declared done in three weeks, followed by six months of “which number is right.” Budget the reconciliation first. It is most of the work and nearly all of the value.

The 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 replica-plus-SQL setup and the DuckDB-and-dbt stack when it’s earned, and run them on retainer, reconciliation included. If you’re unsure which side of the line you’re on, that’s a good first conversation, and when a replica is all you need, that’s the advice you’ll get.

Sources

• Hot Standby: Handling Query Conflicts, PostgreSQL Documentation
• Amazon RDS Read Replicas, Amazon Web Services
• Why DuckDB, DuckDB
• S3 API Support, DuckDB Documentation
• Add data tests to your DAG, dbt Developer Hub
• R2 pricing, Cloudflare Docs