Hacker News new | comments | show | ask | jobs | submit login

I've always found doing logic and processing in the database to be much faster and much more efficient than doing it outside. The closer you can process data to the data store, the faster it goes. Using materialized views can get you a long ways.

There's also no reason why you can't use multiple smaller databases. Use dblink. http://www.postgresql.org/docs/9.1/static/contrib-dblink-con...

I've never had a problem managing "schema and dependencies" on larger systems. Not sure what you are referring to there.

It goes much faster I agree. However you are very short sighted. That black box doesn't go on forever. It will work fine for the first 50 users, seems ok for the next 100, 500 we're doing ok. 1000 BOOM! Then what do you do?

I'd rather have a slightly higher latency and be able to scale to 100,000 users.

Materialized views are not needed with CQRS architecture. ALL tables (or sets) are materialized views already. No joins are ever made.

dblink is ugly and if you ask me a problem, not a solution (latency, network io, memory).

I'm not sure what you classify as "larger" but I'm talking tens of Tb, 1500 tables and over 2 million LOC in the application.


Instagram did just fine with postgresql with 27 million users. Many logical shards spread over a smaller amount of physical ones.



Instagram isn't very complicated to be honest so I doubt that's a good scalability example.


Skype's plan to support 1 billion users w/ postgres a few years ago? http://highscalability.com/skype-plans-postgresql-scale-1-bi... and http://www.slideshare.net/adorepump/small-overview-of-skype-...

Billions of records, 10,000 transactions per second. This was a couple of years ago.

Dunno if Skype is complicated enough for you.


I get the sense he'll ratchet up what "complicated" means until he wins the argument. :)


No just there is a difference between large and complicated.


EVE Online runs on a single SQL Server 2008 instance:


serving hundreds of thousands of users


> At peak hours as of 2007 the database handles around 2-2.5k transactions per second, which generate roughly 40,000 input/output operations per second on the disks.

That's not much...


They're complex transactions. Inserts against dozens of tables, selects from dozens of tables. We're not talking about glorified KV lookups here.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact