Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Current Events
Join our developers event to win one of the valuable prizes!
posted 4 years ago
viewed 9576 times
Share this article

CUBRID vs. MySQL vs. PostgreSQL Release Period Comparison

Warm greetings to CUBRID Community!

There is one thing I can't help telling, I really love CUBRID! Let me tell you why. CUBRID cares about you! Besides being just the most optimized database for Web applications, CUBRID cares about its users a lot. They keep receiving tons of comments from users: some support requests, some feature requests, and some just "thank you" feedbacks. The Korean community is certainly the most active in this case. They have even established the CUBRID Education Center to help Korean users learn CUBRID faster and with a great pleasure. This is exactly what they say: "Let's Study, Develop, and Enjoy Together!"

User Feedback Project! For the global users they have recently started the project with a message "Which feature would encourage you to use CUBRID database for your project?" They do not stop asking users if there is anything more they want to see in the future releases. You just tell what you need for your development, and for the next month or two CUBRID will be committed to having your most requested features included in next release. You doubt? Just go to http://cubrid.uservoice.com and try it yourself. Write your response to "I would use CUBRID if...", join the discussions with other users, and decide together which feature you want to see in the next version of CUBRID.

Release Frequency! Let's see how other database providers cope with it. We will count only major (first number changes) and minor (second number changes) releases and exclude the bug fix releases (third number changes), since 1st number increment indicates on the major change, the second number increments anytime new features are added, or there are some performance enhancements. And this is what important for us users.

postgres_version_days.png

According to End Point's Blog article, the average release period for PostgreSQL is about 288 days since version 6, which is about 9 months. If you take version 7 and onwards, the release period goes up to 367 days. If we look at just version 7, the average is 324 days. If we look at just version 8, the average is 410. Simply put, you have to wait one year or even more to start using your requested features.

mysql-release-history.png

Let's look at the MySQL change history. Version 3.23 was first released in alpha state on Jul. 05, 1999. 359 days later (eleven months and twenty three days) on Jun. 28, 2000, we see the improved 3.23 but still beta. Only on Jan. 17, 2001, 203 days later (six months and 20 days) we see the production release for 3.23. That is, it took one year, six months, and twelve days (562 days) to have the stable release. 4.0 production version has been released 787 days later on Mar. 15, 2003, which is two years, one month and twenty six days. One year, seven months, and 8 days later (588 days) on Oct. 23, 2004, version 4.1 is out. The next major version 5.0 was released on Oct. 19, 2005, 11 months and 26 days or 361 days later. Version 5.1 was released three years and twenty six days later (1122 days) on Nov. 14, 2008. The latest 5.5 Release Candidate is available since Sep. 13, 2010. Based on the latest MySQL Release Model and the historical data, the difference between RC and GA releases for MySQL is about 51 days, which implies that the stable version for 5.5 should appear some time during the next week, possible on Monday Nov. 15, 2010, which is exactly two years or 730 days later since the last release. Thus, in average you have to wait 692 days or almost two years to start using your requested feature in MySQL.

cubrid-release-history.png

Now let's have a look at CUBRID's release history. When the first CUBRID release 1.0 was announced, it was not publicly available and the code was still closed, since it was intended for internal use only. So, we will start the counter from November 22, 2008, the day when CUBRID 1.1 was publicly released as an open source database management system. On Jan. 16, 2009, 55 days later (one month and twenty five days) version 1.2 was released. Then 17 days later on Feb. 02, 2009, 1.3 is out. One month and ten days later (38 days) on Mar. 12, 2009, we have 1.4. On Apr. 16, 2009, one month and four days later (35 days), 1.5 is available. The next major release 2.0 was announced on August 14, 2009, 151 days later (four month twenty nine days). 2.1 comes on Dec. 29, 2009, 106 days later (three months and fifteen days) right before the New Year, they actually made it! 122 days later (four months and one day) on Apr. 30, 2010, here comes 2.2. On Jul. 19, 2010, we have 3.0 beta out, but we will not count it. Five months and four days later (157 days) since the last 2.2 release on Oct. 04, 2010, the major version 3.0 is released. So, last Friday we have 3.1 beta release. Now let's assume when 3.1 production version will be out. Even though 77 days passed before 3.0 beta was stabilized, the CUBRID core developers say 3.1 stable will not take such long and will be out before the year turns. So, we assume Dec. 31, 2010, which is 88 days (two months and twenty seven days) since 3.0 release. In average CUBRID's release period rounds to 85 days, which is two months and 25 days.

Let's draw the conclusion and see how much a PostgreSQL/MySQL/CUBRID user should wait to start using the desired feature.

  • PostgreSQL users have to wait from nine to thirteen months to use the new features.
  • MySQL users have to wait almost two years to start using the requested features.
  • CUBRID users have to wait at most 3 months to start using the new features.
There are many new technologies, strategies, and solutions being introduced almost every month throughout the world. And if there is something which is proven to significantly improve my business operations, I really do not want to wait one year for my solution provider to adopt the new technology. I would rather go with the one who is more responsive, and flexible. Therefore, I strongly believe among these open source database projects CUBRID is the most active and quick to adjust to the rapidly changing environment. Possibly, the gratitude should go to CUBRID's major maintainer [NHN Corp.] for its big commitment.



comments powered by Disqus