https://wiki.postgresql.org/wiki/Replication,_Clustering,_an...

It's my understanding that the Postgres team has decided to change their historical stance of considering clustering solutions outside the scope of the core project, but I'm unclear exactly how far that has come.

The variety of different 3rd party implementations in various states of maturity make this a bit tedious to sort through.

That said, I always pick PG for my personal projects. I just have a hard time getting sign-off on it from my corporate overlords for anything at work.

Async Multimaster is in the list of replication solutions.

I have not personally implemented it myself.

Edit, As I am reading this more closely it may be listing third party implementations and is not 'out of box'

> Are you talking more in terms of support?

Support is not tied to the product's license (which is common for proprietary software).

That's still significantly better than "noone but a single vendor can and you're at their mercy", but just being FLOSS doesn't mean it can't suffer from product lock-in, just that with the hurdle being complexity and not copyright.

Natural complexity, when the domain is simply complex to model, can't be gotten rid of regardless of the product.

If you overcame that and made a patch, but it's not accepted by the upstream - there are maintenance costs. How long would you be able to maintain your own fork of a large software project, keeping up with the upstream? I've tried with a few small ones (say, at a small ISP company, I just needed some custom pppd patches for in-house billing logic), and found it to be not a pleasant experience. I believe it's not just because I'm a lazy ass - I saw tons of forks on GitHub that were slowly rotting away, maintained for some time but eventually forsaken by their authors and far behind their upstreams.

> If you overcame that and made a patch, but it's not accepted by the upstream

As for how well the FLOSS projects are managed, how's your luck at debugging let alone getting a patch accepted in MS-SQL, for instance?

> I saw tons of forks on GitHub that were slowly rotting away

I saw people with food, who weren't eating it because they were full, and I decided that food was stupid. Right?

> How long would you be able to maintain your own fork of a large software project, keeping up with the upstream?

Far longer than a binary patch... You know, to block a certain cipher suite or something in a closed-source product.

Duh, none or nearly none, of course.

I'm not saying that proprietary binary blobs are better. There are exceptions, but generally they're significantly worse in this regard.

I'm only saying that just because software is FLOSS doesn't mean one can successfully hack on it and adapt it to their needs, or easily migrate to other FLOSS solutions. Sometimes, they'll be stuck for a while - I think that's also can be considered as a lock-in.

> Nobody made their code complex because they felt like it.

Maybe. But there's a term "over-engineering" too. It's not that someone decides to make things unnecessarily complex, but sometimes they really do.

It will significantly reduce the licensing implications of using SQL Server for a small project. I know people who use MSSQL in their day job but postgres/other for personal projects and one of the reasons is needing to license Windows if a personal project becomes public and needs hosting. This way a small project can use SQL Server Express on Linux just as cost free as progres (or mysql if you must) on Linux.

The choice of OS will no longer dictates the choice of DB, that decision can be entirely made on the needs of the project and its target users.

Small projects using Express edition may grow into larger ones needed standard/enterprise features, and people exposed to SQL Server through projects using it on Linux are less likely to dismiss ti later because the know postgres/other only. I'm not sure how much we'll see brand new larger projects use SQL Server on Linux any time soon though, but I imagine "get them in at the ground floor and create familiarity as early as possible" is the intention here much like cheap educational licensing for Windows, Office, & full VS and the availability of VS Express.

That said, I use MS SQL both at work and on my personal projects thanks to BizSpark.

There's also Azure, which, to be fair, is still more expensive than an equivalent AWS stack with Postgre or something.

Conversations I had with some senior SQL server team members in the last two years suggested they were ready for no reboot patching but were limited by the OS and felt it was holding them back. If it wasn't for Windows, SQL server uptime would be much better (was the implication)

I'm looking forward to trialing it.

And if you are a start-up, you will upgrade your DB, in which case you might only get a few years free anyway.

Well, I might KEEP my SQL Server, but switch from Windows to Linux as the host OS - to save $$ on licensing and hardware.

(I actually remember using Sybase SQL server for a while until the tool that would eventually be called Enterprise Manager was released.)