What version and how to use free MySQL DBMS in commercial projects? [closed]

Question

Currently, MySQL community edition server 5.5.16 is under GPL. This means that it might be used in projects that are open source projects too. Our project budget is very tight and we need to find a solution to use MySQL free edition in commercial project. I have several questions:

1) What earlier MySQL version would be solid and bug-free enough to use in commercial projects?

2) About using current MySQL community edition server 5.5.16 with GPL: if a project software architecture is designed with support for plugging many DBMSs then is it legal to have a project software under non-GPL license? I mean, suppose the software is designed with multiple DBMS support and the software is put under commercial license. If the client chooses to use MySQL GPL version does he violate GPL license?

3) I heard some negative replies about PostgreSQL being buggy and non-optimized for modifying and storing large sets of data. The only reason it's still used in some small commercial projects is because it's free. What are your opinions on that?

UPDATE: also, we are planning to use several servers, so master-slave replication is also needed.

UPDATE2: I heard about one case: there was used ~1GB PostgreSQL DB. The database was heavily used with updates by modifying almost all data. The problem was the database was constantly growing about ten times every 2.5 month. They have used PostgreSQL 8.3 + CentOS. Also, AUTOVACUUM was used. After dumping database, destroying the old one, recreating database and importing they were able to reduce its size ~10 times. Existing posts (here and here) show that this problem is relative even in latest PostgreSQL 9 version. I wouldn't call it a normal behavior and such size growth is not acceptable in our case.

UPDATE3: thank you all for the answers. All answers are relative and useful for the question.

Answer 1

the other posters have mentioned that basically linking to mysql means you've licensed the project GPL or some other OS license Oracle / MySQL makes an exception for, or it's commercial and you owe them money. Anyway...

OK, PostgreSQL stores its data in a data store that supports MVCC, multi-version concurrency control. This means on a simple level that each transaction gets a snapshot of the database that is coherent from when that transaction starts until it commits or rolls back. This means that at any given time a single tuple can have more than one live version in the database. Because of the way MVCC is implemented in pgsql, those two versions exist at the same time in the data store. Eventually all but the newest ones will be older than the oldest running transaction, and can be recovered and reused by the db. The process that reclaims these old dead tuples is called vacuuming.

In 8.3 the old dead blocks were kept track of with a shared memory segment called the free space map. If either the vacuums aren't aggressive enough OR if you run out of space in the free space map then the database could make dead tuples faster than it could recover them (vacuum) or remember them (free space map).

With 8.4 the free space map becomes maintenance free to the user because it's stored on the hard drive in .fsm files. however the issue with vacuum still exists. autovacuum is tuned to be not too aggressive so as not to kill something like a laptop or a small server when installed. On bigger machines with lots of IO capability like a server with 16 SSDs in a RAID-10 array, you can crank up the aggressiveness of autovacuum and it can keep up with some pretty crazy tps rates. You can get sustained 1,000 to 3,000 transactions per second over long periods on a server with an aggressive enough autovacuum and a fast hardware RAID controller with lots of disks. TPS numbers approaching 10,000 are possible with more expensive and larger servers. All while servicing 100s of connections.

tl;dr: 8.3 is old, and def had some issues. 8.4 and up have better free space recovery but still need aggressive autovac to keep up with a heavy load.

Answer 2

3) I heard many negative replies about PostgreSQL being buggy and non-optimized for modifying and storing large sets of data. The only reason it's still used in some small commercial projects is because it's free. What are your opinions on that?

This is FUD. PostgreSQL is a fully featured, high performance RDBMS used in several large scale deployments.

Answer 3

2) About using current MySQL community edition server 5.5.16 with GPL: if a project software architecture is designed with support for plugging many DBMSs then is it legal to have a project software under non-GPL license? I mean, suppose the software is designed with multiple DBMS support and the software is put under commercial license. If the client chooses to use MySQL GPL version does he violate GPL license?

As soon as you link with a GPL-licensed library, the entire body of code is licensed under the GPL. Oracle makes an exception for other free licenses only.

Answer 4

3) I heard many negative replies about PostgreSQL being buggy and non-optimized for modifying and storing large sets of data. The only reason it's still used in some small commercial projects is because it's free. What are your opinions on that?

ROFL

You must be joking! Pure FUD and nothing else.

We have a couple of TB of data in a PostgreSQL database and it's still growing about 200GB per month. No bugs, no problems, just great performance. Also at 500 concurrent users, no problems at all. Check the mailing list to count the bugs and see how fast these are solved. Don't be surprised when there is a fix within hours. MySQL can learn from that.

http://archives.postgresql.org/pgsql-bugs/

Answer 5

I had the same problem. Earlier i used mysql in commercial projects. But after oracle took over and license policy changes, i looked for other options including SQL-Express, DB2-Express, SQL-lite, PostgreSql

I wont go into the comparisons, because there is lot of information around. But PostgreSql is by far the best with respect to

a) handling large datasets

b) SQL standards

c) Inline documentation

d) Database usage statistics

infact, i could start a project overnight, without any overheads regarding changes in SQL commands OR documentation.

However, since i am using dotnet on windows, Npgsql is the only trusted connector around which scares us.

But so far developing with PostgreSql 9.0 has been absolutely a cake.