Forem: Marcin Niemira

Simple and cheap RAG - genai-toolbox and pgvector

Marcin Niemira — Wed, 18 Mar 2026 10:55:00 +0000

I recently hit a common architectural fork in the road while building my ADK (Agent Development Kit) application.

Initially, I was using Chroma as my RAG (Retrieval-Augmented Generation) backend. It works perfectly for local development, but things got complicated when moving to the cloud. I needed a production-ready, resilient solution that didn't involve managing stateful assets on a Mac Mini or paying for a separate managed vector database.

The solution was already right in front of me: Postgres 🐘.

By using pgvector, you can turn your relational database into a powerful vector store. This is especially seamless if you use Supabase, which can host small databases for free or provide a "Pro" tier for a reasonable price.

Why I Swapped MCP for genai-toolbox

In my previous setup, I used an chroma mcp server. However, for my relational data, I was already relying heavily on genai-toolbox.

I realized I could simplify my architecture significantly by dropping the separate MCP server and Chroma dependency in favor of extending my tools.yaml. In engineering, if I can remove a dependency without losing functionality, I don't hesitate.

Here is the configuration change:

embeddingModels:
  gemini-emb:
    type: gemini
    model: text-embedding-004
    dimension: 768

tools:
  add-document:
    kind: postgres-sql
    source: naati-db
    description: >-
      Adds a document to the RAG database. The 'content' will be automatically embedded.
    parameters:
      - name: content
        type: string
        description: The raw text content to be stored in the database.
      - name: vector_string
        type: string
        # This parameter is hidden from the LLM.
        # It automatically copies the value from 'content' and embeds it.
        valueFromParam: content
        embeddedBy: gemini-emb
        description: This parameter is hidden from the LLM.
      - name: metadata
        type: string
        description: >-
          JSON string representing metadata (e.g., '{"file_name": "tos.docx"}').

  query-documents:
    kind: postgres-sql
    source: naati-db
    description: >-
      Performs a semantic similarity search on the RAG database using the provided query text.
    parameters:
      - name: query
        type: string
        description: >-
          The search query text to embed and search for.
        embeddedBy: gemini-emb
      - name: limit
        type: integer
        description: >-
          Maximum number of results to return.
        default: 5
    statement: >-
      SELECT content, metadata
      FROM documents
      ORDER BY embedding <=> $1::vector
      LIMIT $2::int;

And it works like a dream. Access to data and knowledge is now unified and goes via genai-toolbox

Optimising Docker Builds for Go

Marcin Niemira — Sun, 15 Mar 2026 00:30:00 +0000

This article describes how to improve build time for Docker containers with Go applications. It focuses on speeding up the build process rather than building images from scratch. It's updated(2026) version of my old medium article from 2023

Problem to Solve

Let's start with an issue definition: Building a Go app on a laptop is quick, but building the same app inside Docker takes ages.

Why is building an app on a local machine fast?

Golang produces a binary file. Do you remember C? C also produces a binary file. Let's recap how we could compile a program in C. I promise, we will get back to Go soon.

Let's consider the simplified Makefile below:

CFLAGS := -Wall -Werror
.default: app

.PHONY: app
# Let's cheat a bit and hardcode main.o, foo.o and bar.o
app: foo.o bar.o main.o
    # link object files
    ${CC} -o app $^

# Build ${name}.o based on ${name}.c
%.o: %.c
    @echo building $@
    ${CC} ${CFLAGS} -c $<

# Remove object files and binary
clean:
    rm -vf *.o app

Running make app will build an app artefact. Let's break it down to understand when it's slow and when it's fast.

What if it's a clean build? There are no object files, so CC (clang) will create object files. foo.o will be created based on foo.c, bar.o based on bar.c and so on. Once all object files are ready, CC will link them creating our app. Because creating object files takes time, the build will be slow.
What if make app is invoked again? All object files are already in place, so CC will just link them again. Very little computing power is required, so the action will be quick.
What if we modify only foo.c? Modification to foo.c will enforce foo.o recreation. bar.o will stay untouched. CC will link object files again. Only required files are rebuilt.

The fewer actions the computer performs, the faster the response.

Let's get back to Golang

If you run go help cache:

The go command caches build outputs for reuse in future builds.
The default location for cache data is a subdirectory named go-build
in the standard user cache directory for the current operating system.
Setting the GOCACHE environment variable overrides this default,
and running 'go env GOCACHE' prints the current cache directory.

The go command periodically deletes cached data that has not been
used recently. Running 'go clean -cache' deletes all cached data.

So Golang has a very similar approach; it uses a cache to preserve build outputs. If build outputs are present, less compute power is required to compile the program and local execution is quicker.

How Docker Layers Work

If a layer is already present on the machine, it will be reused. If the layer changes, then all downstream layers need to be rebuilt. As per the picture below, all layers from COPY to the end of the Dockerfile will re-run, which is time-consuming.

Assuming the previous build inside Docker generated 99% of the reusable build outputs, they are not available to the next build because the cache from the old layer is discarded.

Fortunately, Docker offers cache management, which makes it possible to reuse cached files between runs even if layers are changed.

Consider this Dockerfile:

FROM golang:latest as builder
WORKDIR /workspace
ENV CGO_ENABLED=1
ENV GOCACHE=/go-cache
COPY ./src ./
RUN --mount=type=cache,target=/go-cache go build -o app ./...

FROM scratch
COPY --from=builder /workspace/app /bin/app
ENTRYPOINT ["/bin/app"]

Please focus on the GOCACHE environment variable. It has been overwritten to point to a custom location to mitigate operating system and Go installation method differences. Later its location is explicitly specified as a cache for a go build command.

The first run will populate GOCACHE with the actual cache. Subsequent builds will be faster as they can benefit from the existing cache. Assuming only a single file has changed, the vast majority of build outputs can be reused.

Caching Dependencies

Further inspection suggests that changing go.sum or go.mod forces re-fetching all dependencies over and over. Any change to go.sum forces a re-run of all depending layers which includes go mod download.

Can we use the same approach to solve the dependency caching issue? Sure we can. This time we're going to focus on caching GOMODCACHE.

Let's extend the Dockerfile to cover dependencies caching:

FROM golang:latest AS builder
WORKDIR /workspace
ENV CGO_ENABLED=1
ENV GOCACHE=/go-cache
ENV GOMODCACHE=/gomod-cache
COPY ./src/go.* ./
RUN --mount=type=cache,target=/gomod-cache \
  go mod download # line to be removed in final, production ready dockerfile
COPY ./src ./
RUN --mount=type=cache,target=/gomod-cache --mount=type=cache,target=/go-cache \
  go build -o app ./...

FROM scratch
COPY --from=builder /workspace/app /bin/app
USER 65333
EXPOSE 8080
ENTRYPOINT ["/bin/app"]

Both the dependencies and build outputs caches are present and will be used by the Docker build. Only missing dependencies will be fetched and stored with the cache. Let’s consider the picture below.

Green layers are re-run, but thanks to the cache, their execution time is reduced to a minimum. Now Docker build is much faster 🤩.

But are all steps needed?

Nah… We can safely remove:

RUN --mount=type=cache,target=/gomod-cache \
  go mod download

go mod download will pull all dependencies defined in go.mod. go build will pull only those which are actually required and the sequential dependency between the pull and build steps is no longer a concern.

Static Linking with CGO_ENABLED=0

By default, Go might use cgo to link against the host's C libraries (like libc). This creates a dynamic binary that requires those libraries to be present at runtime. Since the scratch image is empty, a dynamic binary will fail to start with a cryptic "file not found" error.

Setting CGO_ENABLED=0 forces Go to produce a statically linked binary. This has three major benefits:

Portability: The binary contains everything it needs and can run on any Linux kernel.
Security: By using scratch, your production image contains zero shell, zero package managers, and zero C libraries, drastically reducing the attack surface.
Size: scratch images are as small as they can possibly be—literally just your binary and any assets you explicitly include.

Performance Impact of CGO

While the primary reasons for CGO_ENABLED=0 are portability and security, there is a tangible impact on build performance. In a clean build environment (like a CI worker), disabling CGO avoids the overhead of invoking the C toolchain (compiler, linker).

For a large project like minikube, the difference is noticeable:

CGO_ENABLED=0: ~32.3s total
CGO_ENABLED=1: ~40.1s total

By disabling CGO, we achieved a ~20% faster clean build 🤯. At runtime, pure Go code also avoids the overhead of stack switching required when calling C code, though for most web applications, this difference is negligible compared to the build-time gains.

tested with minikube codebase as follow

time CGO_ENABLED=1_OR_0 GOOS="darwin" GOARCH="arm64"  \
        go build -tags "libvirt_dlopen" -ldflags="-X k8s.io/minikube/pkg/version.version=v1.37.0 -X k8s.io/minikube/pkg/version.isoVersion=v1.37.0-1765151505-21409 -X k8s.io/minikube/pkg/version.gitCommitID="d96de0585719fe650d457f0055205b427d4b7bdb" -X k8s.io/minikube/pkg/version.storageProvisionerVersion=v5" -a -o out/minikube-darwin-arm64 k8s.io/minikube/cmd/minikube

Solution Limitations

The proposed approach is not limitless. It's ~~2023~~ 2026, a big chunk of work is happening in the cloud with ephemeral workers. This means the cache won't be available for sub-sequential runs, as the worker won't exist anymore.

This issue may be mitigated by rsync. It's possible to rsync the content of the cache to layer and push the builder image to registry or rsync it to the s3/gcs bucket. This solution comes with a price tag: The builder image will be heavy and a time penalty will be added to every build (rsync takes time). It's important to remember that the mounted cache is not stored within the layer, so it won't be pushed within the builder image by default.

Even if further enhancements with rsync and pushing builder image to the registry is possible, I'd suggest checking if the local cache is enough, as the complexity & price tag of the extended solution may outweigh its benefits.

CI/CD and Remote Caching

Fast forward to 2026: Remote Cache Backends have become the "missing link" that solves the ephemeral worker issue. However, it is crucial to understand the distinction between Layer Caching and Cache Mounts:

Cache Mounts (--mount=type=cache): These are designed for on-machine persistence. They are extremely fast but stay local to the BuildKit instance. They are not exported by remote backends.
Layer Caching (--cache-to/from): These backends (like gha or registry) export the finalized image layers to an external service. These are persisted across ephemeral runners.

GitHub Actions Backend

If you are using GitHub Actions, the gha backend is an efficient way to share layer cache across runs. Because type=cache mounts are not exported, you should combine them with a Dependency Layer Pattern for the best results on GHA.

COPY go.mod go.sum ./
# this layer can be cached by layer cache
RUN go mod download

COPY . .
# this layer can not be cached by layer cache. it's only cache mount
RUN --mount=type=cache,target=/go-cache go build -o app ./...

To enable this in your workflow:

uses: docker/build-push-action@v6
with:
  context: .
  file: Dockerfile
  push: false
  cache-from: type=gha
  cache-to: type=gha,mode=max
  tags: my_app/my_service:{{ github.sha }}
  build-args: |
    BUILD_VERSION=${{ github.sha }}

The mode=max tells BuildKit to export all intermediate layers, including your go mod download layer, ensuring that subsequent runs on fresh workers can skip the download entirely.

Registry Backend

Alternatively, you can store the cache directly in your Docker registry. This is useful if you are using a CI provider other than GitHub Actions or want a unified cache location.

docker buildx build \
  --cache-from=type=registry,ref=my-repo/app:build-cache \
  --cache-to=type=registry,ref=my-repo/app:build-cache,mode=max \
  -t my_service .

Summary

Specifying custom paths for GOCACHE and GOMODCACHE provides installation-independent paths and reduces dependency on the underlying OS.

ENV GOCACHE=/go-cache
ENV GOMODCACHE=/gomod-cache

For the balanced performance, you may consider adopting a hybrid approach:

Use Image Layers (e.g., RUN go mod download) for dependencies you want to persist across CI runs via gha or registry backends.
Use Cache Mounts (--mount=type=cache) to speed up local development and internal stages of a single build.

But I'd advise to stick to one approach. Hybrid means problems from both sides.

Let's Talk Numbers

For the tests purposes given Dockerfiles focused on local build performance were added to local copy minikube project.

Dockerfile.with-caching:

FROM golang:latest AS builder
RUN apt-get install -y make
WORKDIR /workspace
ENV GOCACHE=/go-cache
ENV GOMODCACHE=/gomod-cache
COPY ./go.* ./
RUN --mount=type=cache,target=/gomod-cache \
  go mod download # this line exists only to show time saved on fetch step. it should NOT exists in actual dockerfile
COPY ./ ./
RUN --mount=type=cache,target=/gomod-cache --mount=type=cache,target=/go-cache \
   make linux

Standard Dockerfile.without-caching:

FROM golang:latest AS builder
RUN apt-get install -y make
WORKDIR /workspace
COPY ./go.* ./
RUN go mod download
COPY ./ ./
RUN make linux

Changes to source code were done using commands like:

# change code
sed -i "s/expected docker.EndpointMeta/expected docker.EndpointMeta ${RANDOM}/g" cmd/minikube/main.go
# change deps
go get go.opentelemetry.io/otel@main

Results once the cache has been populated by the previous build and the code has been changed:

With caching enabled:
Building 36.0s (14/14) FINISHED

[builder 7/9] RUN --mount=type=cache,target=/gomod-cache go mod download 0.8s
[builder 8/9] COPY ./ ./ 1.6s
[builder 9/9] RUN --mount=type=cache,target=/gomod-cache --mount=type=cache,target=/go-cache make linux 33.6s

Without caching enabled:
Building 114.2s (12/12) FINISHED

[5/7] RUN go mod download 65.7s
[6/7] COPY ./ ./ 1.1s
[7/7] RUN make linux 37.4s

The biggest advantage of caching is shown with the go mod download step, where time was reduced from 65.7s to 0.8s.

Note: This article prioritizes local build speed over CI/CD performance. For CI/CD improvements, you should focus more on the CI/CD and Remote Caching section.

gemini-cli: My Local Hero for packer and systemd

Marcin Niemira — Fri, 13 Mar 2026 05:54:00 +0000

The Local Hero: Automating the Boring Parts of AI Infrastructure

Lately, I’ve been working on an AI agent for a small translation company called insighter. At its core, it’s an agent equipped with some specialized tools and a rather extensive prompt.

Because the project requires stateful resources, I decided to accept "statefulness" as a lesser evil for this specific use case and deployed it to a Google Cloud Platform (GCP) VM. The setup itself is straightforward: Packer for the machine image and a standard deployment pipeline. Nothing too wild.

However, the part that truly impressed me was how easily I was able to do things right. The architecture has several moving parts: the mcp-toolbox, a Chroma vector database, a few other MCP servers, and my own supporting microservice*s* running on localhost. Naturally, these all need to start up in a specific order to function correctly.

I know how to write proper systemd services. I know how to pass environment variables and define startup dependencies. But the "mental tax" of recalling the exact syntax, crafting the manifests, and testing the logic usually takes more time than the quality of such a small solution seems to justify.

This is where gemini-cli became my local hero.

With just a few prompts, it analyzed the local environment, identified the necessary dependencies, and generated clean, production-ready systemd services in minutes. The real win here wasn't just the code generation. It was the ability to delegate the "boring" infrastructure tasks, ensuring the job was done correctly with minimal manual effort.

Key Takeaway

When doing things right is this cheap, taking shortcuts is no longer justifiable.

I’m Not an SEO Guru, So I Built a dynamic Content Engine with Gemini-CLI Instead

Marcin Niemira — Wed, 11 Mar 2026 10:42:07 +0000

How I Used Gemini-CLI and Golang to Scale a Tiny Translation Business from 10 to 600+ Impressions

As life happens, I’ve stumbled into helping a tiny business: a new translation service in Australia called insighter.

Initially, I crafted a simple website. The stack was Golang, HTMX, and Tailwind. It was clean, fast, and... invisible. Google Search Console showed around 10 impressions a day and zero clicks.

Disclaimer: I’m not an SEO guru. I’m just a random engineer who accidentally stepped into the world of Programmatic SEO (pSEO). Here is the 6-step engineering log of how I used LLMs to build a content engine.

Step 1: The Low-Hanging Fruit (Metadata)

I started by improving page quality and metadata. I let gemini-cli do the heavy lifting, generating keyword-rich tags and descriptions for the existing static content.

The Workflow:

Run an SEO checker to find missing tags.
Feed the page context to Gemini.
Manual tweaks to ensure it didn't sound like a robot wrote it.

Impact: SEO tools stopped screaming at me. A solid baseline, but not a game-changer yet.

Step 2: Breaking the "Quality" Rule with pSEO

Google traditionally advises focusing on a few high-quality pages rather than many similar ones. However, Australia has over 2,600 postcodes. I decided to ignore the "less is more" advice and went for bulk generation.

I built 26 templates and programmatically generated pages for different locations. To avoid the "duplicate content" penalty, I got creative:

Unique Visuals: I generated SVG images with random seeds and predefined colors. Every page got a unique fingerprint.
Data Skewing: I built a "fun fact" bank (50 records) and state/territory specific twists (8).

The Math: 2600 pages / 26 templates / 50 fun facts / 8 state-specific twists ~= 0.25.

With a ratio below 1, the risk of an exact duplicate page is nearly zero. Of course this number is skewed as ACT has less postcodes than NWS, but principle stays.

Impact: A visible bump. Impressions jumped by 250–350 per day.

Step 3: Pivoting Keywords (Languages & Countries)

I applied the same logic from Step 2 but shifted focus to Language + Country combinations.

Instead of just "Translation Services," I targeted "NAATI Documents from France" or "NAATI French Translation".

Impact: Another 100 impressions/day added to the tally.

Step 4: Building the "Link Mesh"

Internal linking is SEO gold. Using the distance between latitudes and longitudes, I automated a "Nearby Locations" section.

If you are on the Black Rock 3193 page, the app automatically suggests:

Highett 3190
Cheltenham 3192
Brighton 3187
Mentone 3194

I did the same for languages. Since Switzerland has multiple official languages, the page for Switzerland links to Italian, German, and French. The Italian page, in turn, links back to Switzerland, Italy, and San Marino. This irregular, non-1:1 mapping creates a natural-feeling web for crawlers.

Impact: Harder to isolate, but overall site authority began to climb.

Step 5: Template Variators (The "Mad Libs" Approach)

To make the content even more unique, I implemented DocumentPurposeVariations and DocumentNounVariations.

Instead of every page saying "We translate legal documents," the template uses placeholders like {DOC_NOUNS} and {DOC_PURPOSES}. The engine picks from a bank of grammatically compatible strings. The result? Thousands of pages that are technically different but consistently accurate.

Impact: Unsure yet as it's a fresh change, but the uniqueness score is high.

Step 6: JSON-LD and FAQ Injection

Finally, I focused on Schema markup (JSON-LD). For a postcode like 3022 (which covers Ardeer and Deer Park East), I injected specific FAQ schemas:

Q: Do you provide service in Ardeer? → A: Yes.
Q: Do you provide service in Deer Park East? → A: Yes.

This tells Google exactly what the page is about in a machine-readable format.

Summary

The effort required to do this manually would never justify the gain for a "tiny business." But by treating SEO as a data engineering problem and using gemini-cli as a specialized intern, I built a pSEO solution for insighter mostly in the background.
Does it solve all the problems? Nah, backlinks or authority are not sorted yet, but it's already a huge improvement.

The takeaway: Don't just build a site. Build a system that generates the site.