TL;DR We recently realized that supporting an array of providers in the Prisma schema was premature, adding complexity in the process of improving the product (migrate, native types...), and causing some confusion about our intent.
We are deprecating its use and will consider another solution, better addressing how we want Prisma to support working with multiple databases in the future.
Context
On July 7th, we released Prisma 2.2.0, which came with the following feature: #1487
It allowed to define a provider using an array notation like:
datasource db {
provider = ["sqlite", "postgres"]
url = env("DATABASE_URL")
}We want to deprecate this use and only allow a single provider per datasource.
Why are we doing this?
Our goal at Prisma is to make it approachable to work any database while ensuring people can make the most of them too.
Each database provider has their own strengths and weaknesses, making them fit certain use cases better than others. As an example, SQLite is great to easily get started anywhere but doesn't scale in high-concurrency scenarios.
By allowing a Prisma data source to fit multiple providers, and leaving it up to the environment to decide which provider was active, we made it look like a single Prisma data source could work interchangeably with any of our supported database vendors, despite of their differences. This, in turn, restricts the set of functionalities one can use with their database.
This is not fully aligned with the goal mentioned above.
What we want is:
- to make it easy to start developing using your database of choice (often SQLite as being the simplest for a lot of people) and make it possible to, when the time comes, switch to another database vendor while understanding the implication such a change will have on the schema, your data, and your code;
- to enable developers making the most out of functionalities of their specific database provider, and not feel limited by using Prisma;
- in the future, to make it simpler to have a single application using multiple data sources, each data source being possibly from a different provider.
I was using this! What should I do?
What will happen
In an upcoming release, Prisma will reject schemas that include multiple providers in a data source declaration.
We will communicate this date and update the issue once it's defined. This issue is a heads up so we can let you know of the intent and you can prepare for it.
At that point, this means that the following will no longer be possible:
datasource db {
provider = ["sqlite", "postgres"]
url = env("DATABASE_URL")
}Instead, Prisma will expect to have only a single provider listed:
datasource db {
provider = "sqlite" // or "postgres"
url = env("DATABASE_URL")
}Implications
A situation where we've seen people using multiple providers for a single data source was when SQLite was used in their development environment while Postgres or MySQL was used in the staging/production environment.
This won’t be possible anymore after this change. Note that, while some projects have been famous for doing that, it is also generally considered more robust to align the providers across environments, as the tests will be consistent.
In situations where you started off an SQLite local database, we recommend installing a local instance of Postgres or MySQL on your local machine.
TL;DR We recently realized that supporting an array of providers in the Prisma schema was premature, adding complexity in the process of improving the product (migrate, native types...), and causing some confusion about our intent.
We are deprecating its use and will consider another solution, better addressing how we want Prisma to support working with multiple databases in the future.
Context
On July 7th, we released Prisma 2.2.0, which came with the following feature: #1487
It allowed to define a provider using an array notation like:
We want to deprecate this use and only allow a single provider per datasource.
Why are we doing this?
Our goal at Prisma is to make it approachable to work any database while ensuring people can make the most of them too.
Each database provider has their own strengths and weaknesses, making them fit certain use cases better than others. As an example, SQLite is great to easily get started anywhere but doesn't scale in high-concurrency scenarios.
By allowing a Prisma data source to fit multiple providers, and leaving it up to the environment to decide which provider was active, we made it look like a single Prisma data source could work interchangeably with any of our supported database vendors, despite of their differences. This, in turn, restricts the set of functionalities one can use with their database.
This is not fully aligned with the goal mentioned above.
What we want is:
I was using this! What should I do?
What will happen
In an upcoming release, Prisma will reject schemas that include multiple providers in a data source declaration.
We will communicate this date and update the issue once it's defined. This issue is a heads up so we can let you know of the intent and you can prepare for it.
At that point, this means that the following will no longer be possible:
Instead, Prisma will expect to have only a single provider listed:
Implications
A situation where we've seen people using multiple providers for a single data source was when SQLite was used in their development environment while Postgres or MySQL was used in the staging/production environment.
This won’t be possible anymore after this change. Note that, while some projects have been famous for doing that, it is also generally considered more robust to align the providers across environments, as the tests will be consistent.
In situations where you started off an SQLite local database, we recommend installing a local instance of Postgres or MySQL on your local machine.