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

One reason if you are building a shippable product that needs to work with a variety of client databases rather than a choice of your own.

99% of the time, this is why you build DB agnostic apps.




I am building a product that can work with SQL Server, MySQL, PgSQL and Oracle. The reason was if the company who buys the software already has the infrastructure and DBAs in that database, they can leverage it. If I were making the decision now I would definitely choose just one and stick with it, because

- astonishing amount of things are done differently on these four dbms (idenities/sequences and getting their last value, paging, DDL)

- each of these dbms has specific features which would improve the performance or help us develop stuff but we can't use them because they require different architecture (and we want to keep it the same)

Don't do software for multiple databases. It's just not worth the trouble.


Not to mention even the basic data types are differently named and work differently (text vs varchar vs nvarchar vs varchar2). It is especially hard to when you have to work with date and time types/functions.


The main reason to do that is licensing. You either need to get a redistribution license, or the client needs to work out their own licensing deal -- and either way, you don't want to be beholden when negotiation time comes.

That also applies to MySQL, because it's GPL.

That does not apply to Postgres, because you can just ship it with the app.

I exaggerated a little, there certainly are times when you just don't care what database system you use and would rather have simple migrations at the expense of owning more code. But I think these reasons are weighted much too highly, particularly in the context of postgres.




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

Search: