
Ask HN: What to do when the company behind a database goes out of business? - sajan45
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&#x27;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&#x27;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&#x27;t keep using a DB which is dead? I don&#x27;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.<p>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.
======
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.

------
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.

------
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.

------
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...

