[ZitchDog]

One thing that postgres does not solve very well is reactive UIs. Postgres does have listen/notify but it requires much more boilerplate and infrastructure to set up than Firebase/Firestore. For example I'd like to be able to run a query and get notified that the results have updated when any of the affected rows change.

[samwillis]

Solving this is high on my list with PGlite (https://github.com/electric-sql/pglite). I have a bunch of iteas/thoughts that I hope to get to at some point (IVM, streaming queries, result diffs).

When PGlite (or SQLite) is used with Electric (https://electric-sql.com/), we already provide good reactive primitives. But we hope to improve this so that where possible the full queries don't have to be re-run.

[SparkyMcUnicorn]

I've been very happy using Hasura on top of pg.

There are several fantastic options that remove the need to manually write resolvers, set up subscriptions, solve N+1, reinvent the wheel, etc.

[jamwt]

Agree. If you want a fully reactive database (and not just hierarchy-based reactivity like Firebase) but want to keep your ACID + relational data modeling, check out https://convex.dev .

Plug notice: this is my company.

[cpursley]

Check out WalEx for this, it doesn't suffer from the character limits of listen/notify: https://github.com/cpursley/walex

[j45]

Could a simplification of reactive UIs be a possible angle?

Part of me is thinking about htmx or something from alpine and wondering if it’s enough. Shoutout to livewire too.

[ZitchDog]

Htmx doesn't help with this problem (knowing whether the underlying data has changed in order to update the UI). It's a common problem in any kind of collaborative app.

[j45]

Have you tried Hasura by chance?