IndieWeb community members that use PostgreSQL on their personal sites:
Scott Gilbertson's personal site Luxagraf.net uses PostgreSQL because it's the "only thing that supports GIS data in any real way".
Regarding database-antipattern: I have encountered none of the downsides documented there. but then I don't use MySQL so maybe that's part of it. ... I mean technically all those things apply to Postgres as well, so I might just be lucky.
Shane Becker's personal site http://veganstraightedge.com (powered by Dark Matter) uses PostgreSQL because it's the default on Heroku where the site is hosted, it works well with Ruby on Rails which the site is built with, and because it's Good Enough for what I need/want to do with my site.
Regarding database-antipattern: I also have encountered none of the downsides documented there, in Dark Matter or other Ruby + Heroku apps. I use Heroku's free daily pg backups which are stored on S3 and are relatively easy to rollback to. In addition to the pg backups (which are one big file, in my case about 5mb, per database), I keep a rendered static HTML file per post to my site. I treat these HTML files as backups, not as the primary datastore. I keep those HTML files locally on my laptop, onsite in a Time Capsule and offsite via Dropbox. Because LOCKSS.
Dan Lyke's long-time weblog at Flutterby.com uses PostgreSQL, and personal site at Flutterby.net uses PostgreSQL for managing smaller items like status updates, and for and tracking the state of images and text files.
Regarding database-antipattern: I moved Flutterby.com from HTML files to PostgreSQL in February of 2000. The database lets me easily track comment revisions, throw around ideas faster. Backups to dump files have been as robust as plain text, and even with text files I'd still need to keep some sort of index to find particular locations within those text files ("grep"ping the entire database dump these days takes a quarter of a second, too slow to keep up with the site).
unrelentingtech's sweetroll 1 engine originally used JSON files in Git, but switched to JSON in Postgres. Stored procedures in the database were used to extract embedded entries (comments, in-reply-to contexts, etc.) into their own records when writing content and to embed them back when reading. And to build feeds. Also listen/notify was used for change notifications (a trigger fires a notification on update, the frontend app picks it up and sends as webmentions/WebSub/etc.) sweetroll 1 is no longer used as of 2019.
Regarding database-antipattern: Postgres gave me amazing flexibility — I was able to very quickly implement tags and full text search. It is possible to implement indexes for flat files, or use both flat files and a database, but that was too tedious for me to implement and I implemented nothing.
Secondary Data Storage
IndieWeb sites that use PostgreSQL to store secondary data, i.e. not content that they authored, but content from elsewhere.
Projects which either can or will be able to use PostgresSQL, but which aren't yet in use on an IndieWeb site day-to-day.