So recently, against my best judgement, I’ve started working on a new project. The classic “how hard can it be?” kind of thing. What that actually is is not important right now. More important are the tech choices and how I shifted my opinion on generated code.

The tech stack I went with is what I usually pick; go for backend, pgx and sqlc for database access, htmx for frontend matters. I found managing Go’s template/html always a bit fiddly and wanted a better way of dealing with nested components and being able to render them individually. I have seen templ recommended many times and because it was a new project, I gave it a try. Initially I felt having yet another tool that generates go was weird, but after a few components I was sold.

Hugo has a really way of hooking into the rendering process that I’m using to automatically generate scaled down thumbnails of referenced images. I structure each blog post as a page bundle and render images via ![](image-name.jpg) in the markdown files. By default, hugo will render an image tag with the full sized image which can be rather heavy if it’s a large image. So instead, I set up a render hook for images in layouts/_markup/render-image.html:

In an effort to understand Postgres better I’ve worked my way through how a Postgres database is structured and executes queries.

Process Model

Postgres uses a process-per-worker model. That means every connection is handled by a separate operating system process forked off the initial process.

Subsystem Overview

Postgres consists of several components that all work together to process data and ensure it’s reliably written and can be looked up efficiently. The following are the most important components, but there more, other components that are beyond the scope of this post.

Let me tell you how I was an idiot, ignored best practices, and luckily didn’t lose anything of value. And yes, this is a story about backups.