Skip to content

Safer defaults for usage by making usage of $replicas() opt-in by default #35

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
iheanyi opened this issue Apr 9, 2024 · 1 comment · May be fixed by #47
Open

Safer defaults for usage by making usage of $replicas() opt-in by default #35

iheanyi opened this issue Apr 9, 2024 · 1 comment · May be fixed by #47

Comments

@iheanyi
Copy link

iheanyi commented Apr 9, 2024

Currently, the default behavior of this extension is sending every read query to the replica(s) and every write to the primary. While you can opt-in to using the primary with $primary() , it's default is to always use the replicas for any read. In my opinion, this is a dangerous and unintuitive default, as replication lag could cause unexpected behavior for users if they immediately try to access a newly inserted row after a write.

To mitigate this, a safer default would be to send all reads and writes to primaries by default. This way, there is a guarantee that the reads after writes will always be available. When the user wants to explicitly use replicas, they should call the $replicas() method and chain their queries to it, so this way they are knowingly opting into relaxed consistency and accepting the replication lag that comes with it.

For reference, this is how a lot of other frameworks/ORMs do it. See Django and Rails for example.

@divmgl
Copy link

divmgl commented Oct 29, 2024

+1, came to note the same thing. This is about six months old now. Do we any updates as to whether this will be addressed? We want to issue queries to the read replica but the only other solution is to have a second Prisma client.

@wallforfry wallforfry linked a pull request Jan 27, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants