Derek Sivers's Database and Web Apps
Posted3 months agoActive3 months ago
github.comTechstory
calmpositive
Debate
40/100
Database-Centric DevelopmentPostgresqlWeb Development
Key topics
Database-Centric Development
Postgresql
Web Development
Derek Sivers shares his database and web apps on GitHub, sparking a discussion on the benefits and challenges of putting business logic in the database.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
7d
Peak period
34
156-168h
Avg / period
12.3
Comment distribution37 data points
Loading chart...
Based on 37 loaded comments
Key moments
- 01Story posted
Oct 16, 2025 at 10:27 AM EDT
3 months ago
Step 01 - 02First comment
Oct 22, 2025 at 11:10 PM EDT
7d after posting
Step 02 - 03Peak activity
34 comments in 156-168h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 24, 2025 at 3:57 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45605778Type: storyLast synced: 11/20/2025, 3:35:02 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
For the big idea, see https://sive.rs/pg
I really took Rich Hickey's "Simplicity Matters" talk to heart. https://www.youtube.com/watch?v=rI8tNMsozo0
I've been making PostgreSQL-centered web apps for 9 years that way, by having PostgreSQL just return JSON. Then the "controller" (Ruby or whatever) parses the Mustache or ERB template with the JSON and returns HTML to the browser.
What I'm doing differently now is having PostgreSQL parse Mustache templates directly!
So now the controller just has to pass in the HTTP params, give it to the PostgreSQL function, and it returns HTML ready to return in the HTTP response.
Secondly, what do we do about things like HTML fragments à la HTMX / Datastar hypermedia approach? Do we just hit the DB for 10 lines of HTML to populate the next card in a multi step form?
Then I use this little Ruby script to sync them into the database, which is where they're actually used:
https://github.com/sivers/sivers/blob/master/scripts/templat...
I haven't done HTMX fragments yet. This repository is quite new, and only like 5% done.
Thanks for your response. I didn’t explain myself properly.
Suppose I have a html template that contains the dynamic value {{ foo }}, that template is on my SQLDB, how do I populate {{ foo }} whilst querying the template table?
I hope that makes more sense.
See it in practice here in the unit tests:
https://github.com/sivers/sivers/blob/master/omni/test/templ...
https://github.com/sivers/sivers/blob/master/omni/test/must_...
It comes from these three functions, but really only using the top-level "o.template" function:
https://github.com/sivers/sivers/blob/master/omni/template.s...
https://github.com/sivers/sivers/blob/master/omni/must_templ...
https://github.com/sivers/sivers/blob/master/omni/must_secti...
I'm using it for https://nownownow.com/ and https://my.nownownow.com/ already. Example test:
https://github.com/sivers/sivers/blob/master/nnn/test/mynow-...
It's not new, my first job circa 2007 was working on a Delphi 7 desktop application and all the "business logic" was stored procedures in an Oracle db. It was early in my career but I believe this was fairly popular in the early 00s. I was too young to have an opinion but for sure others will remember and be able to add more colour to it.
Nice seeing you around here! I'm a fan.
But PostgreSQL is not Oracle and doing things this way has been working wonderfully for me for 9 years so far.
1: cooperation, nowadays database instances are cheaper and with Docker we can spin them up but having them shared doesn't feel like a fun thing when developing (triggers more than stored procedures here)
2: version control, kinda ties to the above but being able to keep track of changes (and related then to code being out of sync even if that would matter less in a application-less world)
3: debugging in general ?
4: debuging "spooky effects at a distance" when triggers,etc run.
What's your take on these?
We dont use stored procedures at work, but all other database changes like tables, triggers etc. are committed to git and deployed using github actions. There's no need to run the sql manually
And if you complain that stored procedure language is not so versatile for the business logic, remember that people have been using far worse languages for that, like COBOL, MUMPS, ColdFusion, ...
I was a data analyst and had full access to the database for reporting and data import/export purposes. I had a lot of fun browsing through the stored procedures, which were not locked down or encrypted in any way, and figuring out how it all worked.
I even fixed a bug with a custom module that was causing huge stock valuation errors (I can't believe I even did this now) and also created my own automated order import procedure by monitoring the procedures used by the client's order import screen. Possibly invalidating warranties and support contracts etc. but no problems came of it. They even tried to rehire me a few years later.
So it makes sense to notice what's constant, what's ever-changing, and organize accordingly.
PS been a big fan of your writing over the years and it’s a little intimidating to just respond to one of your posts asking a silly question haha
Some years down the road however this was changing. PostgreSQL began to catch up in terms of simple performance, but also MySQL stumbled on transitioning into a multicore world, while PostgreSQL scaled better due to some of the hard work already being done in the architecture. Additionally we got an included replication option, as well as all the main PaaS vendors providing automation around it. So MySQL's previous advantages became less compelling.
And today, hardware is so incredibly capable that just scaling vertically on a single server is totally viable for a ton of apps. For this swath of the market, just running PostgreSQL has become a bit of a no brainer in the way that MySQL was during the peak of LAMP.
He is a friend and much smarter than me. He told me to switch from MySQL to PostgreSQL. I'm so glad he did.
It's really hard to debug and incredibly difficult to build out automated testing, controlled releases etc.
But I personally find SQL and triggers/stored procedures to have:
- Horrible syntax - Poor LSP support and poor auto complete - poor debugging experiences, error reporting, etc.
I kind of wish someone would make a better syntax with better LSP tooling and solid auto-complete. Geared compiling application logic into databases. I would personally love to see tooling for compatibility analysis too.
It always feels weird that app logic and database are two completely different languages.
https://docs.postgrest.org/en/v13/
https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f...
Now I see the opposite. Web standards can solve the full reload page problem, so it's time to rethink if we still need to manage state in the client, with all the complexity that this involves.
The biggest issue for me it’s the division between backend and Frontend roles. I like to do both, but lately I’m doing backend. It changes a lot how we do things, refinements are mostly to create contracts between the Frontend and backend tasks, we’re they should focus on business use cases.
I have recalled over the years this quote from his presentation: "Your app is sitting on a Ferrari-style computation engine!"
I do a lot of meta link archiving and I wanted to create a link browser. My project supports data in zipped sqlite, or JSONs.
I believe data are as much important as programs, So everything is public.
Links
https://rumca-js.github.io/search - search (JSONs)
https://rumca-js.github.io/music - music (JSONs)
https://rumca-js.github.io/bookmarks - bookmarks (JSONs)
https://github.com/rumca-js/Internet-Places-Database - scripts use SQLite
https://github.com/rumca-js/web_link_browser - clean repo of scripts