We are looking for input on this during the EA phase. Here's how we plan for this to work:

- Each incremental concurrent query allocates additional compute resource to your database - All queries share that pool of compute resource - Queries have strict timeout limits. 10 seconds on most plans configurable up to 60 seconds.

Prisma Postgres is designed to serve interactive applications with users waiting for a response. In a sense, we are adopting some of the design principles underlying DynamoDB (strict limits on queries) and combining it with the flexibility of a Postgres database that is fully yours to configure and use as you see fit.

I don't want limits on the kinds of queries I can run when those limits are artificial ones imposed to work around limitations of a too-simple billing system instead of being inherent in the domain. I'm willing to pay extra for the occasional huge query, but I wouldn't feel comfortable knowing I couldn't make it at all.

That said, a production OLTP workload database would also have query timeout imposed, otherwise those fine folks in the crappy query writing department will surely bring it down.

How much overlap is there in the “serverless database that starts fast” group and the “might have a query that runs for 60 sec” group? If you’re running queries that are that complex, wouldn’t you be better served with a different database service?

If I used two services, I'd have to move data from one service to another.

Having query timeouts instantly makes me write this solution off.

Companies, especially smaller ones starting out, will run analytics in the same DB as the application DB.

A major plus of using a Postgres DB is the flexibility of doing analytics and serving apps. It can do it all. Analytics queries will often easily exceed your timeout limits.