Skip to main content
Prisma Documentation Docs

Search documentation

Type to search this documentation.

On this pageOverview

Known limitations (/docs/accelerate/more/known-limitations)

For the complete Prisma documentation index, see llms.txt. A markdown version of any docs page is available by appending .md to its URL.

Learn about limitations of Accelerate

Location: Accelerate > More > Known limitations

Below are descriptions of known limitations when using Accelerate. If you encounter any additional ones, please share them with us via Discord.

At the moment, it is not possible to cache the responses of raw queries.

Client Extensions (which are used in Accelerate) currently do not correctly forward the fluent API types. We hope to get a fix into Client Extensions soon.

Not compatible with extremely heavy or long-running queries

Section titled “Not compatible with extremely heavy or long-running queries”

Accelerate is designed to work with high-performance, low-latency queries. It is not intended for use with extremely heavy or long-running queries that may cause performance issues or resource contention. While limits are configurable, we recommend optimizing your queries to ensure they fit within the recommended guidelines.

For queries that cannot be optimized or pared down, we recommend one of two solutions:

  1. Use the read replica extension: The Prisma ORM read replica extension allows you to set up two different connections: a primary and a replica. You can set up your Accelerate connection as the primary and then a direct connection as the replica. Any queries that are resource-intensive or long-running can then be routed to the replica, while the primary (your Accelerate connection) will handle normal queries. Please note that this solution requires you to both set up a direct connection and requires the full generated Prisma Client (i.e. without --no-engine).

  2. Separate analytics queries: Our preferred solution is to separate your analytics queries into a separate application. This separate application can then use a direct connection so that it can run heavy queries without impacting the performance or cost of your Accelerate-powered application.

If you have a use case that requires running extremely heavy or long-running queries and Prisma Accelerate, please reach out to us.

Not compatible with direct IPv4 addresses in MongoDB connection strings

Section titled “Not compatible with direct IPv4 addresses in MongoDB connection strings”

Accelerate does not support direct IPv4 addresses in MongoDB connection strings. When an IPv4 address is provided, Accelerate converts it to an IPv6 format to route through its NAT gateway. This conversion may cause the connection string to be considered invalid due to the formatting of the port value.

Workaround: To resolve this issue, create a DNS record that points to your IPv4 address and use that DNS record in your connection string instead of the direct IP.

  • IPv4 connection string (not supported): mongodb://user:password@192.168.1.100:27017/db_name
  • DNS record connection string (supported): mongodb://user:password@my-database.example.com:27017/db_name

For additional details on Accelerate's IPv6-first design, refer to our blog post.

  • FAQ: Frequently asked questions about Accelerate
  • Feedback: Learn where to submit feedback about Accelerate
  • Troubleshooting: Troubleshoot common Prisma Accelerate errors and connection issues
Suggest an edit

Propose a replacement for this page. The site team reviews it before applying any changes.

Export
Documentation menu