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

With RDBMS you have to design the schema first, with NoSQL you don't need to. This is nice when you're dealing with very diverse data (or data you don't even know how it'll look like) or are prototyping. One thing I like about this: You can store your data as it is, you don't have to fit it into your model / world view. You can make sense of it later.

At some point you'll probably have to deal with schema anyway. If this comes at a later stage, you'll have to deal with a lot of diversity and inconsistency on potentially many points. This can become much more painful and time consuming than having dealt with it from the beginning.

If you're thinking about NoSQL as something like a simpler, modern SQL alternative, you're probably having a faster start and a lot of problems in the long run.

Scalability is something, NoSQL databases have for them, definately.

> With RDBMS you have to design the schema first, with NoSQL you don't need to.

Not necessarily, if you have a nice framework. Years ago, I was working on an older Perl application with a tiny self-built ORM (a single class of about 1000 LOC). I gave it pluggable storage backend support and added a prototyping backend where the object is stored into a simple SQL-backed key-value store (a table with columns "id", "type", "data"; where "data" contains a JSON document). So when building something with a new data type, you could just start with the prototyping storage, and once your feature was working, switch to table-backed storage without much code changes.

Not all NoSQLs are document schema-less databases like Mongo. Some NoSQL database systems have static schema. E.g. Apache Cassandra has tables with static column metadata just as RDBMS.

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