The problem what I see with serverless, is if you need to store your state into a database, the classic relational systems will not scale well to the problem.
pbBouncer[0] in transaction mode tries to solve the problem of limited connections by giving a connection from the pool to a transaction. This has a limitation of not being able to reuse statements; e.g. they have to be deleted before the transaction is released, adding an extra roundtrip for the queries. It also means you must wrap every request into a transaction, if planning to use statements. Otherwise the solution is to sanitize all your values and concatenate a single SQL query. It has the big risks of SQL injections and is against all best practices, but this is what Active Record is doing to solve the issue, and I guess it works for them quite well.
pgBouncer has also the statement mode. Here you can't use transactions and with that, no prepared statements either. So you must then just use the text protocol of the database and concatenate the parameters to your query.
Amazon has the RDS, and I haven't looked into it that much yet. What I kind of think I know about it, is it pins the connections when using statements. Meaning, when pinned, the connection is for one client and cannot be reused until disconnected.
MySQL has the serverless-mysql package[1], which is a client side library killing of stale connections and disconnecting as fast as possible when done. So, basically during the request, it reads the system tables and tries to drop the connections from other sessions. I haven't tried this either, but more I think about it, it really doesn't feel like a good strategy at all. For one, you need a root access to the database for every client, and then you need to modify the state of other connections from the clients. There could be a bug in the client library, that is quite nasty to find and can cause really hard-to-fix issues.
Then the last thing is of course the locking of traditional relational databases. They don't scale to massive concurrency that well; the MVCC chokes when running with many parallel queries[2]. So you need a distributed system, something that can have locking mechanisms that can scale to tens of thousands of sudden connections when the serverless system gets a request peak. Hopefully something with a stateless connection. If somebody knows a system that can do this, I'd like to hear about it.
pbBouncer[0] in transaction mode tries to solve the problem of limited connections by giving a connection from the pool to a transaction. This has a limitation of not being able to reuse statements; e.g. they have to be deleted before the transaction is released, adding an extra roundtrip for the queries. It also means you must wrap every request into a transaction, if planning to use statements. Otherwise the solution is to sanitize all your values and concatenate a single SQL query. It has the big risks of SQL injections and is against all best practices, but this is what Active Record is doing to solve the issue, and I guess it works for them quite well.
pgBouncer has also the statement mode. Here you can't use transactions and with that, no prepared statements either. So you must then just use the text protocol of the database and concatenate the parameters to your query.
Amazon has the RDS, and I haven't looked into it that much yet. What I kind of think I know about it, is it pins the connections when using statements. Meaning, when pinned, the connection is for one client and cannot be reused until disconnected.
MySQL has the serverless-mysql package[1], which is a client side library killing of stale connections and disconnecting as fast as possible when done. So, basically during the request, it reads the system tables and tries to drop the connections from other sessions. I haven't tried this either, but more I think about it, it really doesn't feel like a good strategy at all. For one, you need a root access to the database for every client, and then you need to modify the state of other connections from the clients. There could be a bug in the client library, that is quite nasty to find and can cause really hard-to-fix issues.
Then the last thing is of course the locking of traditional relational databases. They don't scale to massive concurrency that well; the MVCC chokes when running with many parallel queries[2]. So you need a distributed system, something that can have locking mechanisms that can scale to tens of thousands of sudden connections when the serverless system gets a request peak. Hopefully something with a stateless connection. If somebody knows a system that can do this, I'd like to hear about it.
[0]: https://www.pgbouncer.org/
[1]: https://www.npmjs.com/package/serverless-mysql
[2]: https://15721.courses.cs.cmu.edu/spring2019/papers/02-transa...