PostgREST: Providing HTML Content Using Htmx

Original Article ↗ Hacker News Discussion ↗

Using PostgREST and htmx to serve HTML directly from PostgreSQL promises an ultra-thin stack—just a database plus a small HTTP layer—for CRUD-heavy or “light” apps. Commenters highlight benefits like no duplicated models, strong RLS-based security, and reduced frontend complexity, but warn about XSS risks, tangled SQL-based templates, performance concerns when serving assets from the DB, and long-term maintainability for larger systems. Many see it as powerful for small to medium internal tools or admin UIs, yet likely insufficient or hard to scale as primary architecture for complex applications.

Use Cases and Maintainability

  • Many see PostgREST + HTMX as ideal for CRUD-heavy, “light” apps, admin panels, and internal tools that mostly wrap a database.
  • Several warn it becomes hard to maintain for mid/large or fast-evolving products: logic buried in SQL/functions, tangled templates in the DB, difficult refactors and performance debugging.
  • Comparisons are made to old PHP/ASP days or Oracle/CouchDB-era HTML-from-DB patterns, which often became maintenance nightmares.

Security, Auth, and Permissions

  • Strong emphasis on isolating an api schema and exposing only views; this is considered essential for non-trivial apps.
  • PostgREST itself follows Postgres’ “deny by default,” but Supabase changes default privileges to “allow,” which alarms some, especially in regulated sectors.
  • JWT + roles + RLS are seen as the primary security model; some find RLS flexible but tricky, others prefer routing writes through separate edge functions.
  • HTML generation in SQL raised serious XSS concerns; the demo initially did not sanitize user input, prompting calls for templating engines with automatic escaping.

HTMX Role and Debates

  • Supporters like the reduced frontend complexity: no build step, minimal dependencies, server-centric logic, “locality of behavior.”
  • Critics argue HTMX still relies on JS, can be tricky for things like validation, and reintroduces HTML escaping pitfalls that SPA frameworks largely avoid.
  • Some view it as another HTML-over-the-wire variant; proponents frame it as “extending/ completing HTML’s hypermedia controls.”

Database-Centric Architecture Pros/Cons

  • Pros: fewer tiers, less code, strong alignment with CRUD use cases, leveraging SQL, views, and stored procedures; can be very fast and conceptually simple.
  • Cons: coupling logic to the DB complicates scaling (DB as bottleneck), testing, debugging, and hiring; DB should be treated as a “precious resource,” not an asset server.
  • Many recommend using PostgREST as a base CRUD layer, with a traditional API or functions for complex logic.

Tooling, Ecosystem, and Alternatives

  • People mention using migration/versioning tools (Squitch, Pyrseas), static-site shells (Astro), and alternative/sql-centric tools (pg_render, plmustache, SQLPage, SmoothDB, Omnigres, jinj.at).
  • General sentiment: better tooling would be needed to make this approach comfortable for mid-to-large apps (templating, migrations, debugging).

Open Source Funding and Governance

  • PostgREST is widely praised, but its small donation base is seen as symptomatic of poor OSS funding.
  • Supabase employs the lead maintainer and sponsors contributors; governance is intentionally shared to avoid single-vendor control.