HN Explorer

Ask HN: What to do when the company behind a database goes out of business?

6 points by sajan45 ↗ HN
In my company, we are looking for a distributed relational database. There are a few options, but I was wondering about how safe is to use something which is mostly developed by a company which relies upon revenue from support packages and other sources? I don't have much experience regarding different databases, but a few names came up like Cockroach DB, YugaByte, Volt DB etc. As far as I am aware, these don't many contributions from the open-source community like Postgres or MySQL. is there any open-source alternative for distributed RDBMS which has good community support? What to do when a company like Cockroach Lab shuts down but you have a product depending on their product, as we can't keep using a DB which is dead? I don't suppose, the data can be moved to some other DB. RethinkDB went out of business and there is almost no commit to the project in Github last year. Does anyone know what did those people do who were using it in a big application? Right now, people in my company have decided to go with Google cloud spanner, which is obviously backed by Google, but expensive.

PS: I am not a DBA or someone who has much knowledge about Databases, just a web developer wondering about things. My apologies if I asked too many questions.

6 comments

[ 3.2 ms ] story [ 24.8 ms ] thread
celticninja
> I don't suppose, the data can be moved to some other DB.

In most cases you can, depending on what you are switching to/from it might be a pain in the ass, but it is entirely feasible.

godot
This is probably more common than you'd think. It's not unlike using open source DBs whose maintainers stop working on it, or even open source code libraries in general whose maintainers stop work. Most likely you will weigh the cost of migrating your data (and/or code) to a different DB/library vs the risk of it not getting security patches, etc.
sajan45
I agree with you. But DBs are way more complex than most of the open source libraries. I know there are some pretty complex libraries but in most of the cases, most of the libraries that the project depends upon can be easily replaced by some other alternative or organisation can dedicate some resources to fork and maintain it themselves. But migrating data from one DB to another DB can be a real pain.
nishantvyas
real question is, why do you need a distributed relational database? when it comes to scale (both in size, QPS, latency) existing RDBMS would just do fine for 95% use-cases. For very small use-cases where you would absolutely need distributed RDBMSs keep some good hygiene of not using DRDBMS specific features, data types etc that can lock you in for future portability/mobility...
segmondy
Know how to get your data out. Say you truly believe something like Cockroach will give you an advantage go for it. But then figure out how to move your data, write abstractions that can make it say easy to switch from Cockroach to Cassandra.

Imagine you're building a software to sell to companies, you wouldn't just support one database, would you? You would build an adapter that will let the customer use Postgresql, MariaDB or MSQL server. You do the same. If you're profitable enough, you support the company, pay them so they can stay in business. Maybe have your devs contribute to the OSS part if they have that. This is something your CTO should be handling. This is also why many mature companies are not gung-ho on using new tech and like to play it safe.

LarryMade2
I have had a few database projects obsoleted when the DB maker has closed down or was bought and the app shot down, shied me away from depending on commercial/activation limited options.

So last time, I went for open source for the DB selected MySQL and haven't look back (now its MariaDB, easy transition) It was open source, easy to use, I could have an installation backup ready if needed, and very popular, might not be shiny new but was dependable for what we use it for.

You may need to find some distributed solution for an OSS DB (or roll your own, depends on the complexity/size), but where there's a will, and good community resources, there is certainly a way. Likely means data conversion, no matter the DB, unless your distributed data, IDs, and tables are basically generic fields, there will need to be some conversion done for any alternative.

Also, if you want long-term, don't go for cutting edge, boring and reliable is better.