5 ms·

Not to start a flame war here, but from the perspective of someone with limited database experience, what is the best database out there? I realize that this qu

Not to start a flame war here, but from the perspective of someone with limited database experience, what is the best database out there? I realize that this question is very vague, but is there a best general-use database?

georgemcbay 13y ago
"Best" is a strong word to use universally, but IMO when in doubt use PostgreSQL. It has a very solid traditional ACID/SQL core and it has also been introducing "NoSQL" style json document storage on top of that for projects that want to go that route. I suspect PostgreSQL will do the the NoSQL type stuff well a a lot sooner than NoSQL databases will do the consistence/durability thing well. Having said all of that on my personal site I actually use RethinkDB because it is delightfully easy to setup and code against (I just persist my Go structs to the db and don't worry about a relational schema to maintain) and I don't really care about data integrity there, so I don't mind that RethinkDB is relatively new and untested. So one size doesn't fit all, but PostgreSQL is still, IMO, generally the "safest bet" if you do care about data integrity and don't want to spend hundreds of thousands of dollars on licensing to scale it up.
- BlackDeath3 13y ago
  Out of curiosity, is there anything to this pairing of languages with databases presented in the link below? Does each database have its own optimal programming language? https://www.gandi.net/hosting/simple https://www.gandi.net/hosting/simple
  - exelius 13y ago
    Generally not; though there are some exceptions given the maturity level of the database drivers in any given language. For the most part though, any well-supported programming language should have a mature driver for any well-supported database.
  - epsylon 13y ago
    The pairing on Gandi's offer has more to do with which database programmers of a given language are usually more familiar with. Hopefully you can use pgSQL in all three cases :-)
bri3d 13y ago
I would use Postgres. It's not particularly likely to eat your data or kill you as you get started, and the ecosystem is relatively unified which means consistent and generally good best practices documentation. Becoming a Postgres expert could take a lifetime as the database offers an astonishing depth of features, but it won't bite you if you just use the basics. Plus the source is quite good if you ever find the urge to dig deep. A couple of gotchas might bother you. You'll need to implement your own strategy for upserts if you need those. But you do get robust native support for popular data types commonly seen in today's apps: geographic data as well as document data (via HStore or JSON). The MySQL/MariaDB family is well-proven as well, but with tens of available storage engines, two core forks, and a bit of non-standard SQL magic sprinkled throughout it's harder for a beginner to learn the best practices IMO. The challenge comes once you exceed what one machine can do and want to move beyond the simple client(s) <-> (possibly replicated) server model. Keep in mind that depending on your project, this might not ever happen to you. Certain types of mid-sized sites like Basecamp and Stack Exchange have gotten away with throwing bigger hardware at their database systems. If or when you reach the point where you need a distributed database, you have to choose between consistency and availability. I'll let the experts explain some of those concepts by linking to this excellent article by Coda Hale: http://codahale.com/you-cant-sacrifice-partition-tolerance/ http://codahale.com/you-cant-sacrifice-partition-tolerance/ . That's when you'll find yourself in the NoSQL world - many NoSQL databases are useful in that they try to trade consistent for available in some way or another. While they generally fail completely to actually do so, as illustrated in Kyle Kingsbury's excellent "Call Me Maybe" series, the largest -scale systems are all based on a "NoSQL" data store in some way or another.
dbpatterson 13y ago
Unless you really know what you're doing, just use a relational database. Opinions differ, but Postgresql is a pretty safe bet.
justinsb 13y ago
You will likely be happy with PostgreSQL or MySQL. If you don't know why you're not using a SQL database, likely you should be. If you do want to experiment with NoSQL databases, MongoDB is probably the easiest to get going with (which is why it is so widely used). However, you seem statistically unlikely to be in the group that is happy with MongoDB in production :-) HBase has a much brighter future for the NoSQL use cases (and is even getting SQL support!)
jmnicolas 13y ago
+1 for PostgreSQL but only if you learn relational database design (it's not that hard). Else you're better off with NoSQL (I found CouchDB amazingly easy).
fennecfoxen 13y ago
SQL databases: Postgres unless you have a reason not to. From the point of view of NoSQL data stores, it'll really depend on your application needs, and I can't give you a full overview, buuuut.... Amazon did a solid job with its DynamoDB database, and Apache Cassandra did a solid job cloning it. I believe I've also heard decent things about the sanity level of Redis and Hypderdex.
- catwell 13y ago
  DynamoDB was released in 2012, Cassandra in 2008, so it is definitely not a clone of the former :) It is loosely based on the Dynamo paper like most modern distributed databases, but Dynamo and DynamoDB are very different things. Riak could be another interesting option in that space. Redis is more adapted for small datasets with high workloads and low durability expectations (i.e. do not host a Bitcoin exchange purely on it unless you really know what you are doing :p).

georgemcbay 13y ago

"Best" is a strong word to use universally, but IMO when in doubt use PostgreSQL. It has a very solid traditional ACID/SQL core and it has also been introducing "NoSQL" style json document storage on top of that for projects that want to go that route. I suspect PostgreSQL will do the the NoSQL type stuff well a a lot sooner than NoSQL databases will do the consistence/durability thing well. Having said all of that on my personal site I actually use RethinkDB because it is delightfully easy to setup and code against (I just persist my Go structs to the db and don't worry about a relational schema to maintain) and I don't really care about data integrity there, so I don't mind that RethinkDB is relatively new and untested. So one size doesn't fit all, but PostgreSQL is still, IMO, generally the "safest bet" if you do care about data integrity and don't want to spend hundreds of thousands of dollars on licensing to scale it up.

BlackDeath3 13y ago
Out of curiosity, is there anything to this pairing of languages with databases presented in the link below? Does each database have its own optimal programming language? https://www.gandi.net/hosting/simple https://www.gandi.net/hosting/simple
- exelius 13y ago
  Generally not; though there are some exceptions given the maturity level of the database drivers in any given language. For the most part though, any well-supported programming language should have a mature driver for any well-supported database.
- epsylon 13y ago
  The pairing on Gandi's offer has more to do with which database programmers of a given language are usually more familiar with. Hopefully you can use pgSQL in all three cases :-)

bri3d 13y ago

I would use Postgres. It's not particularly likely to eat your data or kill you as you get started, and the ecosystem is relatively unified which means consistent and generally good best practices documentation. Becoming a Postgres expert could take a lifetime as the database offers an astonishing depth of features, but it won't bite you if you just use the basics. Plus the source is quite good if you ever find the urge to dig deep. A couple of gotchas might bother you. You'll need to implement your own strategy for upserts if you need those. But you do get robust native support for popular data types commonly seen in today's apps: geographic data as well as document data (via HStore or JSON). The MySQL/MariaDB family is well-proven as well, but with tens of available storage engines, two core forks, and a bit of non-standard SQL magic sprinkled throughout it's harder for a beginner to learn the best practices IMO. The challenge comes once you exceed what one machine can do and want to move beyond the simple client(s) <-> (possibly replicated) server model. Keep in mind that depending on your project, this might not ever happen to you. Certain types of mid-sized sites like Basecamp and Stack Exchange have gotten away with throwing bigger hardware at their database systems. If or when you reach the point where you need a distributed database, you have to choose between consistency and availability. I'll let the experts explain some of those concepts by linking to this excellent article by Coda Hale: http://codahale.com/you-cant-sacrifice-partition-tolerance/ http://codahale.com/you-cant-sacrifice-partition-tolerance/ . That's when you'll find yourself in the NoSQL world - many NoSQL databases are useful in that they try to trade consistent for available in some way or another. While they generally fail completely to actually do so, as illustrated in Kyle Kingsbury's excellent "Call Me Maybe" series, the largest -scale systems are all based on a "NoSQL" data store in some way or another.

dbpatterson 13y ago

Unless you really know what you're doing, just use a relational database. Opinions differ, but Postgresql is a pretty safe bet.

justinsb 13y ago

You will likely be happy with PostgreSQL or MySQL. If you don't know why you're not using a SQL database, likely you should be. If you do want to experiment with NoSQL databases, MongoDB is probably the easiest to get going with (which is why it is so widely used). However, you seem statistically unlikely to be in the group that is happy with MongoDB in production :-) HBase has a much brighter future for the NoSQL use cases (and is even getting SQL support!)

jmnicolas 13y ago

+1 for PostgreSQL but only if you learn relational database design (it's not that hard). Else you're better off with NoSQL (I found CouchDB amazingly easy).

fennecfoxen 13y ago

SQL databases: Postgres unless you have a reason not to. From the point of view of NoSQL data stores, it'll really depend on your application needs, and I can't give you a full overview, buuuut.... Amazon did a solid job with its DynamoDB database, and Apache Cassandra did a solid job cloning it. I believe I've also heard decent things about the sanity level of Redis and Hypderdex.

catwell 13y ago
DynamoDB was released in 2012, Cassandra in 2008, so it is definitely not a clone of the former :) It is loosely based on the Dynamo paper like most modern distributed databases, but Dynamo and DynamoDB are very different things. Riak could be another interesting option in that space. Redis is more adapted for small datasets with high workloads and low durability expectations (i.e. do not host a Bitcoin exchange purely on it unless you really know what you are doing :p).