Ask HN: What to do when the company behind a database goes out of business?
6 comments
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.
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.
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.
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.
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.
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.
> 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.
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.
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...
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.