[sorenbs]

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.

[quotemstr]

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.

[mbreese]

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?

[quotemstr]

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

[dboreham]

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.

[aurareturn]

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.