Comparing different "SQL over HTTP" APIs

It's full compatibility with libpq Postgres protocol vs performance. Libpq is chatty and therefore you incur roundtrip costs. HTTP Post is one shot, but you lose transactional semantics if you don't provide all the queries in the same POST request.

Hi there, fundamentally this is a bit challenging against something vanilla Postgres or MySQL to bolt on since the connection itself is stateful.

Because of the Vitess layer we use, Vitess already has to maintain this with it's internal connection pooler and it knows which connections are bound in transactions on the underlying mysqld. And since Vitess is running "next" to mysqld on behalf of the client, the client is capable of being able to effectively pass around a session cookie with a reference to the in-progress session against the database.

So when the next request comes in, we're effectively saying "please use this bound session id", and vitess says "cool, we got a connection still going for you" and uses that reserved connection.

But tl;dr, it's fundamentally a design that Vitess enables us, and it's implemented effectively with bouncing a Session of state back and forth similar to a browser cookie.

Specifically this protobuf message: https://buf.build/planetscale/vitess/docs/main:vitess.vtgate...