Ask HN: Why are there no easy-to-use highly-available open source databases?
Postgres: A great database but HA options either have far too many moving parts, require manual intervention, are proprietary, or are Fake Open Source. Seems like there's lack of interest in addressing this because companies that sponsor development generate a lot of value off complex operations
MySQL: This database has some odd behavior but that would be fine if it weren't Fake Open Source
MariaDB: HA Options are poor or abandoned
SQL Server: Proprietary
Oracle: haha
CockroachDB: Fake Open Source
YugabyteDB: Fake Open Source. Special shout out here for not even linking to instructions for how to build the database in the readme.
MongoDB: Proprietary, and even before the license change it was Fake Open Source
Cassandra: Not fun to run, and even though I said I didn't care about API I don't necessarily love how it works. But it comes probably the closest?
ScyllaDB: Fake Open Source
TiDB: Fake Open Source
Singlestore: Fake Open Source
FoundationDB: This one comes close but its beginning as a proprietary database really hurt its community, which is way smaller now than it should be. Could grow into something great if more folks got behind it.
etcd: not suitable for use above a couple GB of data
What do I mean by Fake Open Source? A project that has a large percentage of its contributors beholden to a single organization/entity to me is not really open source in spirit. I'm looking for a project where I can feel confident my contributions won't effectively end up behind some proprietary license down the line if/when the VC backed organization that primarily sponsors development decides it needs to protect itself from AWS. If there's an "Enterprise" product and the organization calls the source code for the main project the "Community Edition" or something like it, it's not Real Open Source. If a single organization shuts down and contributions fall off a cliff (https://github.com/rethinkdb/rethinkdb/graphs/contributors) it's not Real Open Source. There are lots of Real Open Source projects with great communities of users/contributors, but many of the newer databases don't have legitimate open source development communities behind them, in my opinion.
I've probably missed some examples. Mostly, I wonder why there hasn't been a general purpose open source database that does the operations stuff as well as the proprietary databases do. Am I missing something?
41 comments
[ 2.7 ms ] story [ 94.0 ms ] threadOut of curiosity: what would your preferred choice(s) be to fit these requirements using existing proprietary products?
Glad to have learned about rqlite from this thread as well.
https://www.percona.com/services/support/high-availability
https://www.percona.com/blog/2021/04/14/percona-distribution...
Then you should use a different term - something like "community project". The single organization projects are still open source, both technically and in spirit.
> I'm looking for a project where I can feel confident my contributions won't effectively end up behind some proprietary license down the line if/when the VC backed organization that primarily sponsors development decides it needs to protect itself from AWS.
If you're talking about ElasticSearch, I'll point out that Amazon forked it and OpenSearch is not behind a proprietary license, so all contributions made to ElasticSearch continue to be available as open source, with improvements being made.
OpenSearch could be a contender (though I did not have fun running Elasticsearch back in the day). I will keep watching it and see how development goes, it's a good call-out.
Why not just use SQLite with streaming replication? It should fit your bill.
Databases rarely have what you would define as real open source with real contributors because the nature of a database means you need one owner and that owner has to be picky and exclude things. Allowing the wrong commit into MariaDB could introduce regressions that no one even could imagine because the complexity of things.
Even when a database starts out the way you describe with good intentions in order for it to become a widely adopted product it has to be pulled in under a single umbrella to direct it and build it toward its vision. This puts it firmly in your fake open source camp.
Not sure why "no cluster size limit" is important given the goals you listed in your comment btw. The rqlite faq mentions a practical cluster size limit of 9 read-write nodes (higher for read-only replicas).
That said, very large datasets (> 2GB) will work, if you've got the disks and memory to handle it. The link above explains how to do it.
Noting the title of this topic, rqlite is specifically designed to be easy to use. I know of no other HA database that is simpler to operate. Installation is trivial, and clustering is easy. You interact with it via a HTTP API.
And you get all the power and quality of SQLite as the database engine.
But larger clusters mean a larger quorum, so larger isn't really better. It depends on what you want. If you want a distributed database where more nodes means more write performance, then rqlite may not be a good fit. rqlite is distributed for fault-tolerance and HA, not for performance.
But if you're looking for some monolith project to provide all of this for you you're going to be in that territory of that fake open source. Because again to build all of this into one tool that has everything from the data access layer all the way down to the metal underneath to ensure that it's replicated and highly available is not a trivial task. Especially if you want things like acid compliance arbitrary joins between data structures and so forth.
The file system is effectively a database of things with an API that accesses those things. Simply a file system of properly named files and directories could meet your needs depending on what those are.
It's the complexity of your access model and methods that will determine what fits your bill.
However galera cluster and/or percona xtradb cluster work remarkably well, considering they’re open source.
https://www.percona.com/software/percona-kubernetes-operator...
Disclosure: I'm CEO at Percona
All the features are open source. Here is how to build from source https://docs.yugabyte.com/latest/contribute/core-database/bu....
> What do I mean by Fake Open Source? A project that has a large percentage of its contributors beholden to a single organization/entity to me is not really open source in spirit.
Well, somebody gotta start the project, no? Feel free to contribute though. Since it reuses PostgreSQL, it directly inherits the "postgresql community commits". The same with being a fork of Apache Kudu fork.
> If there's an "Enterprise" product and the organization calls the source code for the main project the "Community Edition" or something like it, it's not Real Open Source.
The "Enterprise" edition is "just" some scripts that make deployment & monitoring easier (and includes 24/7 developer support). All c++ features are open source.
And it's still young. You can't compare against PostgreSQL that has 20+ years of being available.
I also did eventually find the docs for building the database. It just feels odd to have a roadmap in the readme but no actual information for getting set up on development. It's one of those things (and I grant it's a very small thing) that makes me feel like the platform isn't really for the community.
Probably true as of now. But they have enough funds for some time to seed the project in the worst case scenario.
> It just feels odd to have a roadmap in the readme but no actual information for getting set up on development
Because 99% of developers just want to use it instead of contribute in c++. And the docs are pretty big. We'll include a link for contributors/building docs in the readme.
It takes like 10 years to create a new database ready for production. And not everyone can contribute a quick patch to it, it needs some extensive skills.
But we're extremely open to outside contributors. And we've accepted fixes/features outside of the roadmap. And the license is free enough that you can build a competitor with it.
Source: I work there.
You list several completely different types of databases and then mention you are looking for a "general purpose database".
This tells me you do not understand the problem you are trying to solve, therefore do not know how to define the requirements nor features you require to solve it.
It also tells me you do not understand the difference between different types of databases, nor the niche they fill, let alone why their HA functions very differently.
I'm the creator of this project. While it's not going to work super well at very large datasets, it's explicitly designed to be trivial to deploy, and very easy to operate. You can get it up and running in seconds, and clustering seconds later. My practical experience with databases told me that operating the database is at least as important as performing queries with it. So I put a lot of work into easy clustering, clear diagnostics, and solid code.
The first 'dev' Cassandra install was three nodes. I downloaded the .tar.gz, installed it, started each process in turn on each node with the required configuration.
That was 2012 and there is a chance that cluster is still running. It was low-volume in terms of data. TTL configured so it would never run out of disk. Never had any issues in particular. I used it for ~5 years before concluding work with that client.
The problem in that case was Cassandra proliferated in that small company, they didn't build any particular expertise beyond me, and in the end I was being pulled into discussions from different teams, different products, split across about 13 clusters. Wasn't much fun - but that wasn't the DB's fault.
I’ll admit I definitely fell all the way into “loving” RethinkDB. I still have some sticker bundles from a meetup group merch package. It’s been an agonisingly slow recovery from the company’s demise, but I still hold onto some hope that it can recover and become a multi-stakeholder database with a steady development like PostgreSQL for the horizontal scale document database world.
I run a couple of Postgres databases on cheap linux VMs, for various projects, and they have been running smoothly for years. The only problem I had was two times when the disk was full. If I had multiple nodes they would all have been full...
Github has been down more often than my Postgres databases.
HA adds so much complexity and tradeoffs that I would really think hard about wether it's worth it for your use case.
Jbtw, the risk of nodes dying is quite exaggerated. DO/Vultr/Linode all provide 99.99% up time
* 100% open source (GPLv2)
* Easy replication:
* Easy HA: CREATE TABLE dist TYPE='distributed' agent='...' agent='...'* Real alternative to Elasticsearch in terms of built-in full-text search capabilities, but easier to use.
* Works fine with small and large data volumes: - with in-memory storage for smaller data - with columnar storage (separate library, Apache2 license) for big data that doesn't fit into RAM
* Does analytical queries well
* Not fully ACID-compliant (as well as Elasticsearch, Clickhouse others)