Hacker News Reader

Comment by me551ah | Hacker News Reader

Having migrated a postgres database to dynamodb, I would say that I'm never going to use postgres again.

The problem with all SQL databases is that they are too easy to query and use. You add all kinds of select queries, joins and foreign keys and when traffic hits scramble to make it scale. NoSQL is hard to design but you can atleast be sure that once traffic hits, you don't have to redesign the schema to make it scale.

View on HN

> You add all kinds of select queries, joins and foreign keys and when traffic hits scramble to make it scale. NoSQL is hard to design but you can atleast be sure that once traffic hits, you don't have to redesign the schema to make it scale.

Surely this depends on how you set up your SQL database to begin with? I'm not familiar with NoSQL, so can you explain why "schemas" aren't necessary and scaling happens automatically?

You could design a SQL database to be denormalized from the start, but then you are losing many of the advantages of a SQL database.

I never said that schemas aren't necessary, just that using a strict NoSQL database forces you to think about scaling constraints early. This avoids(atleast partially) a schema redesign later.

Ah yes! Optimize early, that's what my teachers always told me to do. /s

Code is easy to change. Data schemata much less so, particularly in traditional SQL databases.

You don't have joins in NoSQL so you have to keep data denormalized. That means data isn't consistent and you can have an will have (at a high enough data volume) errors if you aren't extremely cautious on how you update and add new data. That might matter or not in a particular business case.

I really hope the GP doesn't work on anything handling financial transactions.

If speed it's only thing that matters, he can use /dev/null for writes and /dev/urandom for reads. That's also very scalable.

Some say that scaling is a edge case. what say you?

Reply on news.ycombinator.com