Has anyone used planetscale.com as MySQL database?
If you have anything that uses components in your models, you will not be able to use PlanetScale for your DB because they don’t support FOREIGN KEY constraint (and will not). But strapi generates sql schema that uses foreign key constraints with ON DELETE CASCADE.
So the error will be:
error Error: ER_QUERY_INTERRUPTED: foreign key constraints are not allowed, see Vitess | A database clustering system for horizontal scaling of MySQL
So yeah, PlanetScale sounds like a good managed DB option but no it doesn’t work with Strapi. Unless, of course, Strapi drop the use of foreign key constraints.
We’ve been using PlanetScale and Strapi for a few months without issue. Just to power an 11ty static site generation, so nothing heavy, but it’s been quite nice. Our dev environment is a Github codespace, so PlanetScale as the db made things really easy
We haven’t noticed any issues using components in the models, fwiw. I suppose if we run into issues with ER_QUERY_INTERRUPTED we’ll know what the issue is now, though
@bflor Interesting! We are giving Strapi a spin for the first time at PlanetScale too. Did you do a custom setup with your own schemas to avoid the foreign keys?
We didn’t do anything special except use a non-main branch of the db (because Planetscale has branches and you can’t do schema modifications on the main branch). And we’ve just continued to use that. It’s not for a production site yet, but seems fine at this point. And probably will remain so for our use case (as backing an 11ty-generated site).
The only issue we’ve seen, which we thought was “normal” but maybe is related to Planetscale, is if certain fields are renamed (in particular, to the same name but different capitalization), Strapi can’t make the schema change it needs to be done manually in the db. Not sure if that’s related to Planetscale, but it’s not been a big problem.
The Strapi CLI way of creating a new project very quickly hits the error because it tried to make foreign keys in PlanetScale and couldn’t. So I am guessing you started out some other way? It did create some of the models though.
My teammate and I at PlanetScale were already talking about the same issue with branching since Strapi was likely going to try to do DDL statements on a production branch, which is not allowed by PlanetScale.
This is interesting topic here
I wanted to give a PlanetScale a try but I am not willing to switch schema creation to a manual mode. And Strapi closed my request for dropping foreign key constraints saying that many devs asked for this feature so it won’t be dropped.
So yeah, on one side there is this great product that is PlanetScale which I would like to use and on the other hand Strapi, which I have already invested in heavily, that doesn’t work with the PlanetScale.
A bit of a bummer.
tbarn do you think there will be any solution any time soon that will allow PlanetScale💘 Strapi without too much of a maintenance/manual handling of schema?
I am curious why this is something enforced by Strapi development team?
I understand the primary ‘concern’. Vitess | A database clustering system for horizontal scaling of MySQL
But simply allowing for a --flag setting in install to circumvent this restriction would be more fitting. It really rubs me the wrong way. Our project is married to strapi but I wont ever use strapi again.