Different DataBases Used in ROR

Hi all i am trying analyze which DataBase is good for ROR if the
application is huge. After goggling i found the following DB used in ROR

  2. MYSQL

apart from above list any other DB are used for ROR and my Questions is
from the above which DB is more faster to fetch queries and to maintain


Oracle is the best option for what you want. If you can afford it
it is a bit expensive) you should go for Oracle but if you want a free
solution then I would recommend MySQL.

Hi Keerthi,

We have been developing very large web applications with MongoDB 

the past 1 year. It’s really cool and very easy to learn.
Give it a try you can find it very interesting and easy to use


Rajesh, I have heard that MongoDB have many limitations. Many of the
servers don’t support it. Also many of the gems don’t have support for
as well. Most gems support sqlite or mysql.

Can i get a brief explanation on Do’s and Dont for the each DB in my
. i mean any link where i can get all those informations.

On Thu, Sep 13, 2012 at 1:47 PM, Kashif Umair L.

Google is the best option for this purpose. All the databases have a lot
pros and cons which cannot be covered here. You can google for pros and
cons of every database.

It all depends on what you need. There is no “use this DB for huge
applications”. Definitely don’t use SQLite in production as it doesn’t

MySQL - can scale well if used correctly and was used by Twitter for a
PostgreSQL - is currently on the rise and a lot of gems start to support
MongoDB - is a NoSQL database and can come in very handy when you have a
lot of documents to store. It scales very well as you can just add new
nodes on the fly.
Oracle - I don’t have any experience with that one.

As you can see it is not possible to answer your question just based on
“which DB is faster and (whoch one) can maintain a big DB”. You have to
more specific on what kind of data you want to store. Do you have highly
connected data? Then you might want to take a look at a graph database
Neo4j. Do you have a lot of unstructured data with varying attributes?
a look at MongoDB.

I’d suggest postgresql, for the sole reason that postgresql supports
transactional migrations, which saves so many headaches and possibly
undoing corrupted database schemas (in the future). It’s also open
as opposed to Oracle - if you get stuck with a problem on the latter,
might be treading in deep water - you’ll have no chance to even look at

That said, it’s ultimately up to you. Do some research, spec out your
system, and I’m sure you’ll choose the right one (or you’ll figure out
pretty quickly if you didn’t).


On Thu, Sep 13, 2012 at 4:17 AM, Kashif Umair L.

Oracle is closed source, if something goes wrong you cannot look at
the source and fix it yourself or submit a detailed bug request. Not
everyone does this but it is an important point for some people. It
also costs a lot of money. Starting with the low end processor license

Standard Edition One = $5,800

up to the top end

Enterprise Edition = $47,500

There are probably other charges and taxes to pay and you will need a
skilled database guy to make the most of it. Whats the point paying
thousands of dollars for a product and then not using it to its full
potential. Unless you have money to throw away :slight_smile:

As to MySQL, at the moment it looks like Oracle is starting to close
that up too, or at least make it less open source friendly. You might
want to give it a wide berth until the dust settles on this one. There
are drop in replacements for MySQL such as MariaDB. Utilise MySQL
skills and tools without lock in from Oracle.

Postgres is good, we use it exclusively.

Sqlite is good for small things but when it gets large I believe (but
have no first hand experience) starts to show its limitations. Perhaps
others with better experience could comment here. The advantage of
MySQL and PostgreSQL is that tools exist to replicate and shard the
database should things get too large for a single database server,
these tools do not exist for Sqlite.

MondoDB is a document based solution and not a relational database so
its use would depend on if your data is better suited to the
relational model or the document model. We found that inserts into
MongoDB were significantly slower than PostgreSQL and so was not
suitable for our needs, pity really because it would have been a
better fit for the data. But we update the data far more often then we
read it.

If your data is really a document model then you might also look at
eXist, an XML database.

@pasha what does this lines mean" you’ll have no chance to even look at
code. "