0 - https://docs.pgdog.dev/features/connection-pooler/prepared-s...
You could argue the BSL is anti-business. But IMHO even that one is only a reaction to abuse. Database companies investing millions in research, development, and maintenance for some trillion dollar corporation to take it and make billions off it without giving back a single penny.
Wow this is very bad. This actually happens in typical Postgres setups?
in pgbouncer the connection is reset via a customisable command [0] which should reset the connection to a clean state.
[0] https://www.pgbouncer.org/config.html#server_reset_query
Example: legacy client A connects to MySQL via the bouncer and says 'I want all of our conversations to use latin-1, not utf-8'. This changes the character set that MySQL parses queries with and returns responses in. The legacy client does some queries and then disconnects.
Now a new client connects to MySQL, and the bouncer just assigns it to the still-open connection from before. The new client is fully UTF-8 compatible and since this is the default for our database it doesn't explicitly say so; it just assumes that UTF-8 is the way to go. Unfortunately, the database server is still thinking in latin-1, meaning that if this new client sends UTF-8 data it will be parsed as latin-1; latin-1 is a subset of UTF-8, meaning that queries will actually work fine unless they need to use a character outside of latin-1, in which case they will get an error, or corrupted data, from the server.
The only solutions around this are:
1. Ensure that every client is using the same settings; if your database is for a single app that uses the same ORM, then this is automatic.
2. Ensure that every client is always explicit about everything it might need to change e4very time, so that every UTF-8 client explicitly sets UTF-8 connections even when that's the default; clients that need utf8mb4 ask for it explicitly and clients that can't handle it ask for something else. One way of ensuring this happens is to configure the server (or the bouncer) to use defaults which are not valid for anyone, or which are going to cause errors frequently and not rarely (e.g. setting the default character set to 7-bit swedish, which would cause frequent errors).
3. Use a bouncer which can either disallow these changes or detect and revert them after the original client has disconnected. I'm not sure if this exists for MySQL at least.
4. Use separate bouncers for each application that might be different (extension of #1); in other words, instead of having a bouncer or set of bouncers for each pool of database servers, you have them for each application; your web app gets one, your legacy reporting tool gets one, your ODBC connector gets one, and so on.
It's kind of a huge mess in theory; in practice, a lot of installations fall into the #1 case so it never matters, but that makes the occasional instance where it does matter extremely difficult to debug.
I believe ProxySQL does exactly that:
* https://proxysql.com/documentation/mysql-prepared-statements...
I wonder if clients send something equivalent to a User-Agent, such that the connection pooler could assign them to different pools automatically.
Every new version of your app has the potential to change behavior in a way that would affect the previous version if the connection was recycled during a progressive rollout.
But I don’t think I would want to create a real database user for every version of the app.
I suppose the connection pooler could map versioned users to the same real user, and use separate pools, but a dedicated UA field is probably better.
Why not? Database users are (usually) not expensive, and with groups you can give access to a group you just add the user to.
Adding this logic to the connection pooler seems more complicated.
Also because it doesn’t really concern the database, it concerns the pooler.
Connection poolers already maintain multiple pools, it would not be complicated at all.
Regardless of popularity, idk, Postgres feels nicer to use for me.
n.b. PgDog isn't an extension
They did? By social media? According to a lot of social media devs Java is also “dead”.
Having said that the issue is MySql / Mariadb is moving more and more behind commercial products e.g. Galera and Heatwave. Postgres continues to be the open community effort.
But hence the divide you see. Large companies. Real traffic use pragmatic solutions to make money. The tutorial developers and hype does whatever.
If your situation doesn't require specialized features of a particular database, then it doesn't really matter. Just pick one. There's too much premature optimization in the world.
If your situation does require something that one database or another excels at, then be grateful that there isn't really such thing as a winner and you can pick the one that works best for your context.
Although I'm the type to shy away from adding extra layers in my architectures when I can help it, pgdog has been an absolute breeze to use :)
I've been slopping together a POC to probe the edges of what can be done as just an extension. So far I have a framed protocol with inline cancellation, named parameters, out-of-query text language selector, ad-hoc pg/PLSQL execution with cache (no need for prepare), multiple result sets, streaming large results, and more flexible bulk upload.
In other words, with this extension you can query:
``` select * from T1; select * from T2; ```
And return them both in PG/PLSQL or straight SQL.
The existing pgwire3 protocol is one of the worst things to work with in postgresql.
We show that it's possible to come close without breaking the DB or the app, but I suspect, it's not quite yet at the level you'd expect from a _durable_ work queue, e.g., Kafka. Not going to replace that one anytime soon.
The notify/listen fix and automatic query routing to read replicas and auto sharding might bringt Postgres finally closer to vitess
Supabase are launching a Vitess for Postgresql, they have hired the original creator of Vitess for it
There will be a couple of production-grade PG vitess solutions the next months.
https://planetscale.com/blog/planetscale-for-postgres#vitess...
...
Supabase one is open from start:
The question was whether your previous statement about it being open source was still the case, or is it now going to be propriety?
Appreciate your company has spent a lot of money on the project.
There will be 0 production grade solutions in the next months, I guarantee it
as per:
https://www.pgpool.net/docs/latest/en/html/runtime-in-memory...
And if writing a server side cursor, probably better to write a stored procedure /function and put the cursor and its logic in it, and then call that rather than handle in application
the honest knock on the streaming kind isn't "bad design", it's that it holds a portal open server-side, which is why it can't survive transaction pooling. so the pooler-friendly fix isn't one giant fetch, it's keyset pagination (where id > last limit n), stateless and constant memory, which is what we moved those paths to.
So, what's better, breaking your app initially so you know to remove that feature, or letting it work silently while the connection pool isn't 100% in transaction mode? Tough call.