from Hacker News

Scaling Rails and Postgres to millions of users at Microsoft

by htormey on 8/28/24, 6:34 PM with 91 comments

• by pajeets on 8/29/24, 12:58 AM

  Postgres can be scaled vertically like Stackoverflow did. With cache on edge for popular reads if you absolutely must (but you most likely dont).

  No need to microservice or sync read replicas even (unless you are making a game). No load balancers. Just up the RAM and CPU up to TB levels for heavy real world apps (99% of you wont ever run into this issue)

  Seriously its so create scalable backend services with postgrest, rpc, triggers, v8, even queues now all in Postgres. You dont even need cloud. Even a mildly RAM'd VPS will do for most apps.

  got rid of redis, kubernetes, rabbitmq, bunch of SaaS tools. I just do everything on Postgres and scale vertically.

  One server. No serverless. No microservice or load handlers. It's sooo easy.

• by cdiamand on 8/28/24, 8:27 PM

  I ran into some scaling challenges with Postgres a few years ago and had to dive into the docs.

  While I was mostly living out of the "High Availability, Load Balancing, and Replication" chapter, I couldn't help but poke around and found the docs to be excellent in general. Highly recommend checking them out.

  https://www.postgresql.org/docs/16/index.html

• by rubyfan on 8/29/24, 11:07 AM

  15 years ago I worked on a couple of really high profile rails sites. We had millions of users with Rails and a single mysql instance (+memcached and nginx). Back then ruby was a bit slower than it is today but I’m certain some of the challenges you face at that scale are things people still do today…

  1. try to make most things static-ish reads and cache generic stuff, e.g. most things became non-user specific HTML that got cached as SSI via nginx or memcached

  2. move dynamic content to services to load after static-ish main content, e.g. comments, likes, etc. would be loaded via JSON after the page load

  3. Move write operations to microservices, i.e. creating new content and changes to DB become mostly deferrable background operations

  I guess the strategy was to do as much serving of content without dipping into ruby layer except for write or infrequent reads that would update cache.

• by teleforce on 8/29/24, 8:28 AM

  Please check this excellent book by former Microsoft and Groupon engineer on scaling Rails and Postgres:

  [1] High Performance PostgreSQL for Rails Reliable, Scalable, Maintainable Database Applications by Andrew Atkinson:

  https://pragprog.com/titles/aapsql/high-performance-postgres...

• by giovannibonetti on 8/29/24, 2:49 AM

  What a small world. Earlier today I got tagged in a PR [1] where Andrew became the maintainer of a Ruby gem related to database migrations. Good to know he is involved in multiple projects in this space.

  [1] https://github.com/lfittl/activerecord-clean-db-structure/is...

• by benwilber0 on 8/29/24, 5:05 AM

  Postgres can scale to millions of users, but Rails definitely can't. Unless you're prepared to spend a ton of money.

• by cies on 8/29/24, 12:05 PM

  My experience scaling up Rails (mostly in size of codebase NOT in size of traffic) really made me love typesafe languages.

  IDE smartness (auto complete, refactoring), compile error instead of runtime, clear APIs...

  Kotlin is a pretty nice "Type-safe Ruby" to me nowadays.

• by neonsunset on 8/29/24, 11:41 AM

  This desperately needs the Walmart treatment of JET.com’s teams past acquisition :)

• by jojobas on 8/29/24, 9:04 AM

  What's Rails and Postgres? Do they mean ASP.NET and MS SQL Server?

• by djaouen on 8/29/24, 1:57 AM

  I don't understand why you wouldn't just use Elixir/Phoenix if you need to scale?

• by datadeft on 8/29/24, 7:32 AM

  Scaling a non-scalabe by default framework that should have been few services written in a performance first language at a billion+ USD company.

  I am not sure why are we boliling the oceans for the sake of a language like Ruby and a framework like Rails. I love those to death but Amazons approach is much better (or it used to be): you can't make a service for 10.000+ users in anything else than: C++, Java (probably Rust as well nowadays).

  For millions of users the CPU cost difference probably justifies the rewrite cost.