Postgres is enough until it very suddenly isn't

"Just use Postgres" has been the correct opening answer to most database questions for a decade, and analytics kept being the exception: row storage grinds on wide scans and aggregations. In 2026 the exception narrowed. pg_duckdb reached 1.0, embedding DuckDB's vectorized engine inside the Postgres process, with reported speedups of 10x to 100x on analytical queries against the same data. Vendor-adjacent numbers, but consistent with what columnar execution does everywhere else, and the sensible deployment advice (run it on a read replica so analytics never touches write latency) is refreshingly free of magic.

the case for staying

One system means one backup story, one access model, one operational surface, zero pipelines. For a company whose analytical data is gigabytes to a few hundred of them, and whose consumers are a handful of dashboards, Postgres plus a vectorized extension is not a compromise; it is the correct amount of infrastructure. The single-node argument applies with extra force when the single node already exists and someone already knows how to run it.

what the extension route actually requires

The one-system story stays honest only with two disciplines. Pin the analytics to a replica from day one, because the first time a quarter-end aggregation adds latency to checkout writes, the argument for consolidation dies in a war room. And treat the extension like the infrastructure it is: version-pin it, test upgrades against a restored backup rather than in place, and confirm your managed provider even allows it, because the hosted Postgres services differ sharply on which extensions they bless and how quickly they track releases. None of this is exotic, but it is exactly the checklist teams skip when the pitch is "you already run Postgres, there is nothing new to operate". There is something new to operate. It is simply much smaller than a warehouse.

the three signals the honeymoon is ending

Analytics load starts shaping how you size and operate the transactional database. History accumulates past what one node stores comfortably. Or access sprawls: many teams, external parties, role-based governance that Postgres grants were never designed to express at scale. Any one signal is survivable; two means start the warehouse evaluation before the third arrives.

verdict

Postgres-first: worth adopting as the default posture, and pg_duckdb moved the boundary meaningfully. Just write down the exit signals now, while nobody is emotionally attached to the current architecture. Every "just use Postgres" story ends; the good ones end on schedule.