As Odyssey maintainer, I have to admit that it is exceptionally difficult to achieve stability (e.i. quality) of PgBouncer.
It has two limitations: it is single threaded and it is developed only re-actively. PgBouncer docs used to say that prepared statements can never be supported, in 2022 we supported it in Odyssey and then PgBouncer implemented it too.
In a sense Odyssey is developed to motivate PgBouncer development. To provide alternatives that keep PgBouncer from stagnation.
Yet, I can't say that scalability with SO_REUSEPORT is a good solution.
With Odyssey we have customers with 50k+ connections operating normally.
Also consider SQPR - it's a connection pooler with sharding capabilities. It handles data migration between shard on top of request routing. Odyssey will inherit this capability once it is stable enough in functions set.
It's slightly different from recommendations by draft RFC version (there's no counter), but fully within spec requirements. From practical point there's no difference at all.
I concur that Odyssey docs are insufficient to build a big picture. But I'm trying to answer every question in the Internets about Odyssey :)
Documenting is hard - everything seems obvious to me, but understand that may things are not that obvious.
// Odyssey maintainer
I think the book is free because Egor and PostgresPro want to develop the community. If you want to pay back - you can just start contributing to Postgres. No need to wait :)
It seems like there's issue when you have a user for accessing authentication table you login with the same user.
It fails when due to mixing same pool for auth and for work. I'll look into differentiating these pools more closely.
As a simple workaround you can setup different user for accessing password and not login into Odyssey with this user.