Open source databases: What are they and why do they matter? For developers, there is no debate. The future of the database is open source. A glance at the 2022 Stack Overflow survey of around 70,000 code-wranglers shows nearly all pros use one of the two leading open source RDBMSes, PostgreSQL (46.5 percent) or MySQL (45.7 percent), although they use other systems as well. Oracle, …
In the real world "For developers, there is no debate. The future of the database is open source" is misleading, developers have a preference for open-source because they don't have to pay for it, but they also don't want to be the one to support it - devs would rather be an Oracle developer rather than a PostgresSQL DBA.
For businesses the question does not primarily relate to license costs, but to recovery cost in failure, or support cost with performance problems. The problem comes with complex HA clusters and DR failover where there is little interest devoting time, and those that do, do-so because they work for a cloud vendor. Total cost of ownership of PostgresSQL vs MS SQL/Server is not necessarily in favor of open-source, especially when management insist on a support contract.
The "investor community was pretty clear that open source is a dying" either relates to dumb investors, or investors looking at Snowflake and thinking that $12billion company shouldn't exist if the answer is open-source.
With the move to cloud computing, the cost driver is scalability of managed instances rather than license cost of instances
TCO is always difficult to work out but anything is cheaper than the system not running. But a lot of companies have found out that despite all the pay for licences and support, they get poor support. I've heard this particularly from Oracle. After all they've already got the cash and know that companies can't switch easily, especially if they buy up the competition, which both Oracle and IBM are good at. S&P 500 companies can probably afford to pass things up to the C-suite but there are plenty of smaller companies for which Oracle, et al look like costs plus contracts.
With the rise of companies providing commercial support for open source databases and managed hosting some companies are finding they have a choice. Companies that provide support only have a greater incentive to provide solutions than those that can also look forward to juicy licence fees.
Personally, I'm not keen on companies thinking they can skimp on DBAs by moving their data entirely onto someone else's platform but I can certainly see arguments for some degree of managed hosting.
devs would rather be an Oracle developer rather than a PostgresSQL DBA.
Trust me, no dev wants to be an Oracle developer. PL/SQL is arcaine, and using Oracle as anything more than a database is a path to vendor lock in hell.
Oracle's a very competent database, but using it feels like typing all the way back to the 90s.
COMMIT WORK; RELEASE;
A rising tide lifts all ships… apparently.
It will cost Amazon more to maintain their own completely private fork of Postgres than contribute relevant patches to the project now and then. But they're perfectly able to do that if they wish. Seeing as their revenue is based on the service they provide (managing the infrastructure rather than developing application) they're quite free to do just that.
The licence was chosen to make it easy to fork. And, of course, they'll have forked if they want a version tuned for their needs, not least for release management. But that doesn't meant they don't engage with upstream developments: they'd be missing out on some pretty good stuff and incorporating in a completely separate tree will become increasingly difficult.
You're absolutely right - just look at what happened with Elasticsearch,
Amazon doesn't want to fork $DB product because of money and cost, not because of some altruistic reason,
To add - there actually *is* a fork of Postgres... sort of. The "serverless" databases they offer as the Aurora product run Postgres (and MySQL), and the code underneath is surely a hacked-up fork of that DB.
It seems odd to talk about how FOSS databases are dominant in startup culture without mentioning that an Oracle database license costs five figures per CPU. If you're using Postgres or similar and you become capacity constrained and want to expand, you shell out an extra $10 per month to AWS or whoever and spend a few hours configuring it all. If you run Oracle and want to do the same, you call your local salesman and tell him you're bent over, ready and waiting. In a time when software scalability is everything, what sort of startup wants to expose themselves to the risk that they'll be successful and need to buy more Oracle licenses at whatever the hell the going rate is then? It's not like you'll have a choice; shell out or your service will fall over.
" In a time when software scalability is everything, what sort of startup wants to expose themselves to the risk that they'll be successful and need to buy more Oracle licenses at whatever the hell the going rate is then? It's not like you'll have a choice; shell out or your service will fall over."
This not only applies to startups but big companies as well. When Oracle changed their licensing to apply by CPU, in the mid 00s if I recall, the big DC I was working in received eyes watering bills to cover.
After that, every new DB would be on OSS, and they desperately tried everything to get rid of Oracle DBs.
I'm wondering who is still installing Oracle DBs those days ...
MariaDB seems to have become the favoured RDBMS for many FOSS applications. This mention of BSL, therefore, worries me somewhat. I run a NextCloud server at home on a Pi. This is undoubtedly production - several directories on my laptop sync with it every day. Should I have a paid for licence? If not, how is this differentiated from production that does require a paid-for licence?
That confused me as well, this was the first I have ever heard of this BSL thing (when did that come into being?). Most, if not all, Linux distros have been gradually moving away from MySQL to MariaDB over the past few years, with no mention of this new licence and any potential issues that it may cause (or, at least, not being very vocal about it, if they have noted it).
But the MariaDB(.com) website still says there is a free MariaDB Community Server edition, although it doesn't make it very obvious what licence applies to it. Presumably you can find the details on further digging, but it's very definitely not good practice to not make the terms clear up-front.
Interestingly, the MariaDB page on Wikipedia (and they might just happen to have a particular interest, given that they use it themselves!) says that:
The MariaDB Foundation mentions:
MariaDB Server will remain Free and Open Source Software licensed under GPLv2, independent of any commercial entities.
Perhaps not surprisingly, it seems that the .com website tries to confuse in a spew of marketroid dribble, whereas the .org site tries to explain, but maybe relies too much on volunteers and 'copious free time' to keep it properly up to date?
The .com site is perfectly clear too. The author of the article got confused for no good reason.If you hover on "products" or click "pricing" or "downloads" in the main navigation its made clear, and if you go to the licensing FAQ
In fact MariaDB cannot make changes to the core product license because the copyright belongs to Oracle. Not unlike Apple and Google and others with Blink/Webkit browsers derived from KHTML.
Cockroach DB is partially BSL, but note that the BSL now means features are released as proprietary and automatically relicensed as open source a few years later. Its somewhat like the terms for Qt - although that is enforced by a contract with the KDE Qt Foundation AFAIK rather than being part of the license.
If you are running on a Pi, have you considered SQLite? It is more capable than many think: SQLite.org - Appropriate Uses for SQLite (Websites).
Firstly, if you install something from Raspbian repositories it is save to assume you can use it pretty much any way you want, they probably would not distribute something with restrictions like that. And if you want to be extra sure you can always use plain Debian, which is really strict about licenses.
Alternatively, you could consider using Postgresql instead. I run a Nextcloud instance with Postgresql on a low end VPS just fine. I have no reason to assume it won't also work fine on a Raspberry Pi.
There is a new version of SQL Server in CTP (aka preview) edition at the moment: SQL Server 2022, but you'd never know it.
Microsoft treats SQL Server as a burden these days. It's Azure or nothing. And not everyone wants to go cloudy.
How dare you run software on-premises?
SQL Server is not going to go away but with the amount of love it is receiving, I do wonder if there will be another version this decade.
And with all the love & support that SQL Server receiving from Microsoft, I see posts for PostgresSQL more often now on SQL Server noticeboards, fora and the like.
It is good to see Microsoft indirectly supporting Open Source.
SQL Server is a mature product. SSMS is a pretty good tool. So serious question, what does it need that would require a new release? The only thing that really causes me grief is the config program for SSRS has to run as local admin. I'd also prefer the Failover Cluster manager to run under some group besides local admin so that DBAs could move roles between nodes, but that isn't part of SQL Server.
> SQL Server is a mature product. SSMS is a pretty good tool. So serious question, what does it need that would require a new release?
Barring a few nice-to-haves - some of which will be in 2022 - I'd agree with this.
I work with SQL Server by trade so I'm biased, but I've also used Oracle, Postgres and MySQL.
What you get with SQL Server is a very mature product with excellent tooling, documentation and support, nothing else ticks all those boxes at once. It's also excellent at doing what it's designed for - crunching *relational data*.
If you want to do non-relational stuff or some massive custom scaling solution then yeah, look elsewhere.
Few new features in 2022: you can truncate dates and they've added greatest and least functions. All of those are already in PostgreSQL.
I've move from MS SQL to Postgres over the last 2 years. Mainly due to customer pressure. There are things I miss about MS SQL (SSMS mostly). The problem for MS is that once people are on open source, there is little reason to go back to paying for this stuff.
Not only on-premise, but using SQL Server in a cloud provider other than Azure seems to be a bit awkward these days. Not necessarily as as a server DB, but hosted on virtual infrastructure within a cloud provider.
I notive htere's a thing going on now when a new solution is provided, the thought process is to see if it can be done with Postgres or Maria, and if there is anything in SQL Server that compels its use. SQL Server still a strong candidate, but more and more stuff is being picked up by Postgres. There has been for a long time a thing for avoiding Oracle and removing Oracle if it's infested anywhere.
perhaps if Micros~1 were to switch to PostgreSQL (and stop calling it "sequel") rather than using SQL Server as its basis. A handful of compatibility add-ons for PG could be easier than maintaining an entirely separate code base...
but of course the add-ons would have Micros~1 licensing so not sure how well THAT would work out.
Perhaps taking the results of the Stack Overflow developer survey as representative of whatever point you would like to make isn't as persuasive as you might imagine.
Just as an example, you won't see much DB2 or IMS or VSAM because mainframe developers mostly don't ask their questions on SO. They usually have a support structure built into their organization.
-> MariaDB, a fork of MySQL, and CockroachDB, a distributed RDBMS, adopt what they call a Business Source License (BSL). This is a "new alternative to closed source or open core licensing models,"
MariaDB was forked from the GPL version of MySQL. How is it possible to relicense it under a different license?
How is it possible to relicense it under a different license?
The answer hinges on use of the proper pronoun: MariaDB is a “them” rather than an “it”. The MariaDB server was forked from MySQL, and remains under the GPL. The MariaDB client libraries similarly remain under the LGPL. Neither the server nor the client libraries have been relicensed. To date, only the MaxScale and ColumnStore Cluster Management API products are licensed by MariaDB Corporation Ab under the BSL.
I work almost exclusively with MSSQL, both as a dev and dba.
I would like to use Postgre, but as far as I know there is no 'decent' tool for deploying a the db changes from version control.
This is the major issue for me switching to PG for new projects, I do not want to deal with manual db deployments/ incremental scripts etc. especially when multiple devs work on it (devs are usually pretty bad with DB)
SSDT/Database projects, despite taking sometime to get right, work amazingly, It's a pity there is no such a thing for PG
This post has been deleted by its author
AFAK, there is no management and administrive tooling as the one for SQL Server Databases. I'm working also with MySQL, Redshift, MongoDB and no client get no even close to that.
I've to agree that in this new days of Devops methodologies the way to go is go back to scripting all, but for certain task, having the managements tools, both graphical and text, provided by the main vendor should be a must.
(and yes, I'm old enough and definitively not fond of this new shiny web consoles)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
