Microsoft already announced the SQL Server on Linux licensing:

https://blogs.technet.microsoft.com/dataplatforminsider/2016...

"A customer who buys a SQL Server license (per-server or per-core) will be able to use it on Windows Server or Linux. This is just part of how we are enabling greater customer choice and meeting customers where they are."

Same editions, same prices.

Thanks for the information! Apparently I missed that in the news stream.

Sad to hear about that though. I was hoping for a break. Will just have to continue reading that PostgreSQL book I've already started.

Now that someone has downvoted me, I know it is the right choice and I must learn Postgres. Thanks for your support, folks.

PostgreSQL is the right choice, no matter what.

I'm starting to learn postgres as well, which book if you don't mind me asking?

I've started with the book "PostgreSQL Up & Running". It's rather lacking in detail and has a lot of typos, but I'm nevertheless enjoying it. It's written in a simple language and it provides a good landscape overview, which is exactly what you need in the beginning. Get the big picture first and then you can look for the necessary details as you go.

http://shop.oreilly.com/product/0636920032144.do

Why limit yourself with Express/ Community if you can get full featured RDBMS with Postgres?

For a developer favoring .NET, the degree of .NET integration with SQL Server might be a compelling advantage for applications where the limitations of the relevant SQL Server tier weren't a problem.

Because I really like the power of SSDT (SQL Server Data Tools) and how nicely it integrates with Visual Studio and would like to continue using that instrument if possible.

But I can't seriously build a complex product around SQL Server knowing that 10GB is the sky for my database.

You can go ahead with PostreSQL if you use Entity Framework and Code First approach. I used it many times and I was able to quickly jump from PostreSQL to MS SQL and back. It just works. With EF I don't see any reason why I should tie to any particular SQL database

Personally, I prefer writing SQL by hand. That way I know exactly what will happen in a query. A database really is an important component of a system and shouldn't be treated like a dumb data store where you just throw in any stuff you like through an ORM and hope it sticks there somehow.

Lots of people do exactly that (treat it like a dumb data store) and are wildly successful. Do what you want, but don't say other people shouldn't do it a different way which has been proven to work.

False dichotomy, you can use both together and get the benefits of both an ORM and raw sql, each when they're the better choice.

Certainly. Yet there's been a tendency later to declare SQL wrong and deprecated and to incite everyone to forget about it and go with an ORM as the only way. I do not accept that. The stronger the ORM zealots are pushing the more repulsive the idea of an ORM becomes to me. But of course it's just another instrument that has its place among the others.

Only among the inexperienced. Skilled people use both as needed, even at the same time. You can keep the complex SQL in a view and map the view with the ORM. ORM's are far too valuable to ever hand write all that SQL and SQL is far too flexible to ever ORM 100% of every use case, the ORM should make up most of the program with hand written SQL sprinkled in where useful when the ORM is clunky.

It's easy enough to do that, you don't HAVE to use an ORM framework. Though mapping sprocs to an Entity model is easy enough... I've had to do that several times where performance in EF was particularly bad.

I would be surprised if there wasn't a free (as in beer) Express version for Linux, with a DB size limit like 10GB. Otherwise Entity Framework Core supports PostgreSQL, but there isn't any lazy loading yet.

I don't believe it works outside of using EF. Last I checked no database drivers existed for .NET Core for MySQL and PostgreSQL. For that reason I've stuck to Django.

npgsql is the open-source default driver for PostgreSQL and works with .NET core (netstandard 1.3):

https://github.com/npgsql/npgsql

I believe you can use PostgreSQL with Dapper, as there is an ADO provider for PG, but I haven't tried this.

https://github.com/StackExchange/dapper-dot-net#will-dapper-...

What I meant was that's just not enough. You can toy with it in a hobby project but in production that will be exhausted pretty soon.

I think that probably depends pretty heavily on what your app is. One of my clients has about 200,000 user accounts (and 40K actives/week) in a database that's well under 4GB, and it's been live for three years now. It's in Postgres, but there's nothing that'd stop them from using a 10GB-capped SQL Server Express until a point where having to pay for SQL Server is a good-problem-to-have.