backstage icon indicating copy to clipboard operation
backstage copied to clipboard

Implement additional database support

Open freben opened this issue 4 years ago • 12 comments

Feature Suggestion

Implement official support for more databases!

Backstage has been prepared from the start to support multiple databases, and a lot of the ground work is in place - we use the knex library for both database queries and migrations, and we are mindful of different database engines when constructing the different plugins. We also have some support in place for continuously running tests against many database engines.

So far, we have been concentrating on PostgreSQL for production use, and SQLite for development use. But we want to expand to support the other database engines that knex supports. The remaining ones at the time that this was written, are MSSQL, MySQL, MariaDB, Oracle, and Amazon Redshift.

Possible Implementation

At least the following parts may be affected:

  • Extend the test utils to more engines
  • Update the backend-common database code, in particular the DatabaseManager and its connectors folder.
  • Go through all of the database migrations (e.g. folders like this), and make sure that they can complete successfully
  • A lot of existing tests should be fleshed out to actually make use of the above mentioned test utils

Databases

These are the engines that are supported by Knex, that aren't yet officially supported by Backstage. This can be used as a progress tracker - please link related pull requests to this one, and tick off the box when they are merged and deemed complete!

  • [ ] MySQL
  • [ ] Amazon Redshift
  • [ ] MariaDB
  • [ ] Microsoft SQL
  • [ ] Oracle

Context

See https://github.com/backstage/backstage/discussions/6241

freben avatar Jun 30 '21 14:06 freben

One would assume that we should have support for Redshift already as it's Postgres compliant. Worth a try though to confirm first maybe.

benjdlambert avatar Jun 30 '21 14:06 benjdlambert

Yep and since it has a dedicated entry in the knex docs, it led me to believe it at least had some different behaviours somewhere - perhaps in the database creation stuff at least, or regarding auth, or connection string format, or ... yeah you know.

freben avatar Jun 30 '21 15:06 freben

I think this in general goes for some of the hosted solutions, right? It may be the case that they have some layer of service account auth or other things that get in the way of the full end-to-end picture - even if the SQL queries that run inside the finally established connections happen to be exactly compliant

freben avatar Jun 30 '21 15:06 freben

I would really like to STRONGLY push back against this : What problem does supporting multiple databases solve ?

b) Is this being done because Knex can support multiple databases ? Do we actually have a usecase where multi-DB support is needed ?

Multi-database is tricky. there are simply far too many differences between the behavior of various RDBMS and it might be easier to support multi-cloud deployments correctly than dealing with multi-DB solutions.

Given that most organizations are going to deploy backstage as a green field project, I don't think there is any reason to support non-Postgres (maybe Redshift) databases (and keep this project simple)

GoWind avatar Jul 12 '21 17:07 GoWind

I am not sure I understand the motivation of the issue, does multi-database mean running different engines side-by-side? Is that the intended goal?

For our use-case, what we would like is to be able to run MySQL as RDBMS instead of the current options (SQLite/Postgres). Internally we have set up infrastructure to support scaling MySQL database clusters, and have tooling and experience operating it. In that sense, it would be a big plus and a reason for us to adopt Backstage if it did fit with our existing database offer.

julioz avatar Sep 02 '21 15:09 julioz

Yeah, only one db at a time! MySQL is indeed the one I'd prioritize highest to add. The issue is about making sure that the existing backstage code can run successfully on a larger number of database engines than today.

freben avatar Sep 02 '21 16:09 freben

We would also like to have MYSQL to be supported in Backstage. For the same reason as @julioz, our internal teams have more experience scaling/operating MYSQL.

shoukoo avatar Sep 14 '21 05:09 shoukoo

We would also like to have MYSQL to be supported in Backstage. For the same reason as @julioz and @shoukoo, our internal teams have more experience scaling/operating MYSQL.

silvaleandrodp avatar Oct 13 '21 20:10 silvaleandrodp

We'd love some help to make this happen!

freben avatar Oct 14 '21 07:10 freben

I´m also expecting to have mysql support, i would appreciatte if you could make it

josesimon avatar Mar 08 '22 09:03 josesimon

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Jul 15 '22 14:07 github-actions[bot]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Sep 19 '22 09:09 github-actions[bot]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Nov 21 '22 08:11 github-actions[bot]

I work with a team that wishes to run their own version of Backstage for a large organisation. The org is not able to use PostgreSQL and requires MySQL or MSSQL. Lack of support and guidance for additional databases may hinder the eventual adoption of the platform.

Are there any recommendations on how we could support a different type of database?

barmatz avatar Nov 23 '22 11:11 barmatz

Supporting another database would be a fairly large effort not just once but also over time to make sure it's properly supported going forward from multiple individuals or an organisation that are willing to invest time and effort long term. We currently use sql features in catalog and likely in other plugins that vary slightly from the different SQL implementations so we would have to thread carefully to make sure that it works across versions but also not to pollute the code with if statements depending on vendor. We already have quite a bit of comparisons between postgres and sqlite where those two differ. This is in the back of our mind in the maintainer team but is unfortunately not a prioritised effort currently.

jhaals avatar Nov 24 '22 15:11 jhaals

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Jan 23 '23 15:01 github-actions[bot]

Hello, @freben we're looking to contribute and add MySQL support to Backstage. What is the best way to proceed? Open a new issue (feature request)? Asking mainly due to the checkbox about whether the feature request has been raised before. Thanks!

dalvarado avatar Jul 11 '23 23:07 dalvarado