It can but it's not the primary goal at the moment. If you want to restrict the number of rows returned, you can rewrite the query to add a LIMIT clause. To control which rows your users can see, you can use row-level security.

One thing I was thinking of doing is generating query plans asynchronously and blocking/cancelling queries that would otherwise be expensive and cause downtime. That's on the roadmap.

Will do. You're not the first one to recommend this, it's about time I listen.

You shard posts on posts.userid as well, same hashing function, same number of shards.

Paginating over millions of rows isn't really done in OLTP use cases that PgDog is targeting, as far as I know. Would be great to learn about yours though. Feel free to reach out!

There is a bit documentation about configuring foreign keys here: https://docs.pgdog.dev/configuration/pgdog.toml/sharded_tabl...

Medium term I can see detecting foreign keys automatically (if constraints exist).