Return to Answer

I posted a pretty detailed answer on stackoverflow about when it is appropriate to use relational vs document (or NoSQL) database, here:

Motivations for using relational database / ORM or document database / ODM

Summary:

• for small stuff, go with whatever tools you are familiar with

• a few gigabytes is definitely small stuff: it doesn't get big until it is too big to fit in a single MySQL Cluster with a reasonable number of nodes (16-32), which means maybe 8-16TB data and a few million transactions per second (or a more conventional hard-drive-based database with up to 100's of TB data and a few thousand transactions per second).

• if you're stuck with another database (not MySQL Cluster), get more mileage out of it by throwing in FusionIO hardware.

• once you have data larger than a few TB and faster than thousands of transactions per second, it is a good time to look at moving to logical sharding in the application code first and then to NoSQL.

• Cassandra :)

I posted a pretty detailed answer on stackoverflow about when it is appropriate to use relational vs document (or NoSQL) database, here:

Motivations for using relational database / ORM or document database / ODM

Summary:

• for small stuff, go with whatever tools you are familiar with

• a few gigabytes is definitely small stuff: it doesn't get big until it is too big to fit in a single MySQL Cluster with a reasonable number of nodes (16-32), which means maybe 8-16TB data and a few million transactions per second (or a more conventional hard-drive-based database with up to 100's of TB data and a few thousand transactions per second).

• if you're stuck with another database (not MySQL Cluster), get more mileage out of it by throwing in FusionIO hardware.

• once you have data larger than a few TB and faster than thousands of transactions per second, it is a good time to look at moving to logical sharding in the application code first and then to NoSQL.

• Cassandra :)

I posted a pretty detailed answer on stackoverflow about when it is appropriate to use relational vs document (or NoSQL) database, here:

Motivations for using relational database / ORM or document database / ODM

Summary:

• for small stuff, go with whatever tools you are familiar with

• a few gigabytes is definitely small stuff: it doesn't get big until it is too big to fit in a single MySQL Cluster with a reasonable number of nodes (16-32), which means maybe 8-16TB data and a few million transactions per second (or a more conventional hard-drive-based database with up to 100's of TB data and a few thousand transactions per second).

• if you're stuck with another database (not MySQL Cluster), get more mileage out of it by throwing in FusionIO hardware.

• once you have data larger than a few TB and faster than thousands of transactions per second, it is a good time to look at moving to logical sharding in the application code first and then to NoSQL.

• Cassandra :)

I posted a pretty detailed answer on stackoverflow about when it is appropriate to use relational vs document (or NoSQL) database, here:

Motivations for using relational database / ORM or document database / ODM

Summary:

• for small stuff, go with whatever tools you are familiar with

• a few gigabytes is definitely small stuff: it doesn't get big until it is too big to fit in a single MySQL Cluster with a reasonable number of nodes (16-32), which means maybe 8-16TB data and a few million transactions per second (or a more conventional hard-drive-based database with up to 100's of TB data and a few thousand transactions per second).

• if you're stuck with another database (not MySQL Cluster), get more mileage out of it by throwing in FusionIO hardware.

• once you have data larger than a few TB and faster than thousands of transactions per second, it is a good time to look at moving to logical sharding in the application code first and then to NoSQL.

• Cassandra :)

I posted a pretty detailed answer on stackoverflow about when it is appropriate to use relational vs document (or NoSQL) database: http://stackoverflow.com/questions/13528216/motivations-for-using-relational-database-orm-or-document-database-odm/13599767#13599767

Summary:

• for small stuff, go with whatever tools you are familiar with

• a few gigabytes is definitely small stuff: it doesn't get big until it is too big to fit in a single MySQL Cluster with a reasonable number of nodes (16-32), which means maybe 8-16TB data and a few million transactions per second.

• if you're stuck with another database (not MySQL Cluster), get more mileage out of it by throwing in FusionIO hardware.

• once you have data larger than a few TB, it is a good time to look at moving to logical sharding in the application code first and then to NoSQL.

• Cassandra :)

I posted a pretty detailed answer on stackoverflow about when it is appropriate to use relational vs document (or NoSQL) database, here:

Motivations for using relational database / ORM or document database / ODM

Summary:

• for small stuff, go with whatever tools you are familiar with

• a few gigabytes is definitely small stuff: it doesn't get big until it is too big to fit in a single MySQL Cluster with a reasonable number of nodes (16-32), which means maybe 8-16TB data and a few million transactions per second (or a more conventional hard-drive-based database with up to 100's of TB data and a few thousand transactions per second).

• if you're stuck with another database (not MySQL Cluster), get more mileage out of it by throwing in FusionIO hardware.

• once you have data larger than a few TB and faster than thousands of transactions per second, it is a good time to look at moving to logical sharding in the application code first and then to NoSQL.

• Cassandra :)