2 ms·
If the database stays small and the load stays low, sure. But, as things grow, you tend to run into problems with analytical loads adversely impacting, and eve
by mumblemumble 5y ago
If the database stays small and the load stays low, sure.
But, as things grow, you tend to run into problems with analytical loads adversely impacting, and even knocking over, the production system by locking resources and causing timeouts. Especially if you're allowing analysts to run ad-hoc analytical queries.
Long story short, yes, resiliency is expensive, but it's not always more expensive than not having resiliency.
- Footkerchief 5y agoRead replicas can take the brunt and have widespread availability in Postgres cloud providers.
- marcosdumay 5y agoI do order the solution in "you should choose the simplest one that doesn't disrupt your environment" as: Use a single database for transational and analytical workloads. Replicate your transational database as is for analytical workloads. Remodel your data and replicate to the exact same technology stack. Remodel your data and replicate into specialized tools for analytics. I have never seen anybody that actually needs the last one. But the largest environments I've looked are government databases with a few thousands of people working on (there are bigger envs out there).