SQL Server Express alternatives beyond 2GB limit

Question

In our project (which is fully developed using .NET), we use a medium sized database about 2 GB in size. Currently we are using SQL Express edition;

How do the alternates for SQL Server Express perform? I am mainly considering MySQL and PostgreSQL. (Windows 7 x86, x64)

• Is there any compelling advantage to using MySQL or PostgreSQL?
• What about the native .NET object support?
• Built in XML types?
• Supporting Binary data?
• Support of a similar tool like Management Studio?
• Installation ease?
• Memory footprint?
• Performance comparisons of these 3 databases?

Is it even worth considering these alternatives, especially considering the fact that we are a .NET shop?

I have referred to these related questions:

• http://stackoverflow.com/questions/1371560/db2-vs-postgresql-vs-sql-server
• http://stackoverflow.com/questions/3779088/database-that-can-handle-500-millions-rows
• http://stackoverflow.com/questions/336275/mysql-versus-sql-server-express

Answer 1

I'm a person who doesn't believe just because you are a .NET shop that you have to use a Microsoft SQL Server Product, although Microsoft loves it if you do. Of course it ties in really nicely with the native libraries and development tools from Microsoft. To me that's where the advantages really stop for SQL Server and it's more of a even playing field with other database systems.

MySQL - Stay away from it, things have gotten ugly and will get uglier now that Oracle owns it. Not worth having to pay to use a second rate open source database in my opinion when you can use PostgreSQL for free and without fear.

PostgreSQL - A really good option. BSD license is free to use and change the source. No limit on data lot's of features. But if install time is your driving reason to leave SQL Express PostgreSQL does install pretty fast on Windows or Linux, how fast I don't know because I don't care if it takes 1 minute or 10 minutes on my systems. On a Linux box it's really fast if you pre-compile it or use a package install, I would say less than 10 minutes.

What about the native .NET object support? Not sure what this is.

Built in XML types? PG yes.

Supporting Binary data? PG yes.

Support of a similar tool like Management Studio? PG yes pgadmin or a few other third party vendors.

Installation ease? Easy with more options than SQL Server. For example you can compile with different page size if you wanted to.

Memory footprint? Can be small or large depending on how you adjust memory settings.

Performance comparisons of these 3 databases? Well SQL express can't hold more than 4 to 10GB forget how much 2008 express can do. So you aren't comparing apples to oranges here. But I would say all of them can perform well if used correctly. PG performs very well.

Is it even worth considering this alternative (especially considering the fact that we are a .NET shop)? Yes it's worth considering but depends if cost matters to you. My guess is at some point you will out grow the express edition and have to start buying a payed version. Microsoft knows how to sell and it's part of the model that you will out grow express. You can't go wrong going with PostgreSQL if you have the chance to test it and validate it in your environment use this time to compare. Don't just default to SQL Server because your a .NET shop.

Older post that adds to this and is even more true today. http://archives.postgresql.org/pgsql-advocacy/2005-07/msg00008.php

Answer 2

If you using stuff like LINQ to SQL it takes a little more attention to make it work, and MySQL and PostgreSQL are not supported that well.

I finally achieved what I wanted with MySQL using DBLinq but it took some time.

Answer 3

Current Versions

---

• SQL Server 2008R2
• PostgreSQL 9.0

Function comparisons

---

• SQL Server 2005 vs MySQL 5 vs PostgreSQL 8.3

  Some mention of SServer2008 has been noted in the comparison. I'm not too sure about the differences between the Express edition and the enterprise edition.

Benchmarks

---

• PostgreSQL 8.3 vs SQL Server 2008

  Conclusion: PostgreSQL 8.3 (old version) can contend with SQL Server and when tweaked can outperform it.

Answer 4

I would agree much about PG with StarShip3000 said.

About MySQL, I think it's too much dooming speech about Orcle owning it. It is still remain being developed as Open Source. Maybe they sell a commercial version, but they already did it while as under MySQL AB.

Speculations apart, I have some points to bring about MySQL. As it has some nice feats, has equally bad points.

For example, MySQL is most know for being a super duper fast RDBMS. And it is. When tables are using MyISAM engine. What this means? Means that even a simple requirement as foreign keys consistency will not be available. Then you can imagine about all the rest.

If you use InnoDB engine for MySQL tables, then you can count with FK, safe transactions, but a performance not as fast (pretty in the same level as PostgreSQL, which is good). Ah, and you cannot count with full-text search feature for example.

MySQL is this: or you have performance, or have a decently ruled database, but never both.

Postgre, which is my choice, is fully featured. Does not have the MyISAM tables performance, but is fast enough.

Most people does not know, but Postgre is even more full featured than you can imagine. Let me tell you guys about a nice thing on PG. It counts will a genetic algorithm on its query parser.

Query parser is the piece who parse the query and decide what plan should follow to extract data you asked. When it parses a query, it can achieve some different ways to extract same data. It picks the most probably fast, and execute. But it executes other plans too sometimes, to check if it is good or not indeed. And logs stats about those runs.

Along the time, it knows, through statistics, what is the fastest plan to run, so it gets faster on its own. How much you use it, faster it gets. If tables changes, this process allows it to optimize itself.

OK, I've talked too much.

Well, I truly does not know M$ Express Server, so, I can't talk about it. But Now I think you have a better panorama about Postgre and MySQL.

Cheers.