DEV Community: özkan pakdil

MariaDB vs MySQL vs PostgreSQL: an mpazari Benchmark

özkan pakdil — Wed, 23 Sep 2026 00:00:00 +0000

I recently compared MariaDB, MySQL, and PostgreSQL using the realmpazari.com application. The goal was not to produce a synthetic database benchmark. I wanted to answer a more practical question: does MariaDB really have an advantage when an application sends many simple queries?

This question came up after reading an argument that PostgreSQL is obviously faster than MySQL, but that MariaDB should be faster for applications with many simple queries, while PostgreSQL is probably better for complex joins. The suggestion was that a MariaDB versus PostgreSQL comparison would be more interesting than a PostgreSQL versus MySQL comparison.

I had already migrated mpazari.com from MySQL 8 to PostgreSQL 12. That migration made the server feel much lighter, but it did not answer the MariaDB part of the question. So I restored the same data into MariaDB and MySQL and compared those results with the earlier PostgreSQL run.

The application

mpazari.com is a Turkish motorcycle classifieds site. The application is a Spring Boot 4 / Java 25 GraalVM native image with hand-written SQL. The home page is not a single complicated query; it performs several small reads for listings, taxonomy data, counts, and footer information.

The database is modest by production standards, but it is real application data rather than a generated benchmark dataset:

31 tables
20,750 rows in motor_ilanlar
approximately 111 MB of data used by the tested workload
roughly five simple database queries per home-page request

That makes this a useful test for this particular workload, not a universal ranking of database engines.

Test setup

I used the same Hetzner server for both runs: 8 cores, 32 GB of RAM, and Ubuntu 20.04. The system was otherwise idle, with the load average below 1 before the tests.

The important comparison details were:

The same pre-cutover dump was restored into MariaDB and MySQL: 31 tables and 20,750motor_ilanlar rows.
The same application build and runtime settings were used for the MariaDB and MySQL runs.
The application was freshly restarted before each main run.
MariaDB and MySQL listened only on 127.0.0.1.
MySQL ran in Docker with --network host, so there was no NAT or proxy hop.
MariaDB used port 3306 and MySQL used port 3307.
k6 ramped to 50 virtual users for one minute, held that load for five minutes, and ramped down for one minute. Each iteration loaded the home page and slept for one second.

The PostgreSQL numbers come from an earlier same-box benchmark against the live stack. That stack speaks PostgreSQL-dialect SQL, and its PostgreSQL instance hosts several sites’ databases, so the PostgreSQL result is useful context rather than a perfectly engine-pure comparison.

The k6 thresholds were p(95) < 200 ms and p(99) < 500 ms.

Main benchmark

Metric	MariaDB 10.3.39	MySQL 8.0.42	PostgreSQL 12*
Average	125.52 ms	132.40 ms	156.97 ms
p(95)	129.73 ms	139.43 ms	171.86 ms
p(99)	182.13 ms	150.07 ms	177.16 ms
Maximum	229.31 ms	243.90 ms	287.17 ms
Requests	16,025	15,930	15,590
Failed requests	0%	0%	0%
Database RSS peak	141 MB	411 MB	1.7 GB**
Load average, 1-minute average / peak	0.88 / 1.34	1.27 / 2.01	–

MariaDB was about 5% faster than MySQL on average and about 7% faster at p(95). PostgreSQL was about 25% slower than MariaDB on average in the contextual comparison. The MariaDB and MySQL difference is real, but not dramatic. All three results passed the latency thresholds comfortably.

The more interesting result is the tail: MySQL’s p(99) was 150 ms, compared with 182 ms for MariaDB, while PostgreSQL measured 177 ms. MariaDB won the average and p(95), but MySQL handled the slowest one percent of requests more consistently in this run.

* PostgreSQL was measured in the earlier live-stack run, with different SQL text and a shared cluster.

** The production PostgreSQL instance hosts several sites’ databases, so its CPU and memory cannot be attributed to this workload alone.

A smaller CPU comparison

I also ran a smaller 15-VU test for two and a half minutes. The databases were equally warm when this test started.

Metric	MariaDB 10.3.39	MySQL 8.0.42	MySQL 8.0.42 (`performance_schema=OFF`)	PostgreSQL 12*
Average / p(95)	125.12 / 130.26 ms	130.25 / 136.35 ms	130.81 / 136.82 ms	158.7 / 169.2 ms
Database CPU average / peak	0.2% / 1.0%	6.6% / 9.0%	8.3% / 10.0%	n/a**
Database RSS	141 MB	411 MB	162 MB	1.7 GB**

* PostgreSQL was measured in the earlier live-stack run.

** PostgreSQL CPU and memory are not attributable to this workload alone because the instance is shared by several sites.

For this workload, MariaDB used noticeably less CPU. The application sends many uncomplicated queries, and MariaDB’s executor appears to handle them with less overhead. This is the result that most closely matches the original claim.

The CPU numbers should not be interpreted as a general statement that MySQL is expensive. The tested request rate was low and the database was mostly waiting. At this scale, a few percentage points of CPU do not affect the SLA, but they may matter on a smaller server or at a much higher request rate.

Memory and `performance_schema`

The first MySQL run used 411 MB of resident memory, compared with 141 MB for MariaDB. That looks like a large difference, but the defaults are not equivalent: MariaDB ships withperformance_schema disabled, while MySQL enables it by default.

With performance_schema disabled, MySQL used 162 MB. That is much closer to MariaDB’s 141 MB, so the original memory comparison was mostly a configuration difference rather than an inherent 900 MB advantage for one engine.

What this does and does not prove

This benchmark supports a narrow conclusion:

For this application, with many simple queries and a small, fully resident dataset, MariaDB 10.3 was slightly faster on average and used less CPU than MySQL 8.0. The available PostgreSQL context was slower on this box, but it was not an engine-pure comparison.

It does not prove that MariaDB is always faster than MySQL or PostgreSQL. It also does not show how any engine would behave with large joins, analytical queries, writes under contention, replication, different indexes, or a much larger dataset.

There is also a version caveat. MariaDB 10.3 is a 2019-generation release, while MySQL 8.0.42 is current. A comparison with MariaDB 10.6 or 11.x might produce different CPU and latency results. MySQL 8 features such as CTEs and window functions were not relevant to this workload.

Conclusion

The simple-query prediction held for mpazari.com. MariaDB was approximately 5% faster than MySQL on average, 7% faster at p(95), and used much less CPU in the smaller comparison. The contextual PostgreSQL result was approximately 25% slower than MariaDB on average, although its different SQL dialect and shared cluster make that comparison directional rather than definitive. MySQL had the better p(99) in the main run, and its apparent memory disadvantage largely disappeared when performance_schema was disabled.

The differences are interesting, but they are not large enough to make the database engine the bottleneck here. Both databases passed the SLA easily. For this application, schema design, indexes, caching, connection handling, and the rest of the server stack are more important than choosing between MariaDB and MySQL based on a 5% average-latency difference.

So the answer to the original question is: yes, MariaDB can be faster for many simple queries, and this real application showed that pattern. PostgreSQL was slower in the available contextual run, but that result needs a like-for-like rerun before making a strong engine-level claim. The MariaDB advantage over MySQL was small, workload-specific, and not enough to make MySQL an unreasonable choice.

From Spring Boot to Rust: Rewriting a Live Marketplace

özkan pakdil — Mon, 21 Sep 2026 00:00:00 +0000

From Spring Boot to Rust: Rewriting a Live Marketplace

mpazari.com spent years on a legacy ASP.NET stack — the .aspx URLs still in the wild prove it. A recent Spring Boot rewrite replaced that engine, first as a JVM jar, then as a GraalVM native image to tame memory usage. The question that started this project: if we rewrote the whole application in Rust, what would we gain, what would we break, and how do we prove we broke nothing? This post covers the rewrite, the parity hunting, the server-side build/deploy pipeline, and the load test comparing all three runtimes on the same production box.

1. Why, and what exactly

The goal was not a rewrite “someday”. It was: same database, same URLs, same behavior — different engine. Every page had to behave identically to the aspx version:

Aspect	Java (old)	Rust (new)
Framework	Spring Boot / MVC + Thymeleaf	warp 0.3 + hand-rolled filter chain
Templates	Thymeleaf (`th:*` attributes)	minijinja 2 (Jinja syntax)
DB access	Spring JDBC / NamedParameterJdbcTemplate	sqlx 0.8, plain SQL, same PostgreSQL schema
Sessions	Spring Session	stateless HMAC-SHA256 signed JSON cookie
Deploy artifact	GraalVM native image (112 MB) or fat jar	single 21 MB binary

2. The load test: same box, three runtimes

Method:

Same machine (Hetzner, Ubuntu 20.04), same PostgreSQL data, same Apache-less path — k6 maps www.mpazari.com straight to the app port (9100) via /etc/hosts override, so the measurements are app-only, no proxy noise.
k6 scenario: ramp to 50 VUs in 1m, hold 50 VUs for 5m, ramp down in 1m; each iteration fetches the home page and sleeps 1s.
Thresholds: p(95) < 200ms, p(99) < 500ms.

Runtime	avg	p(95)	p(99)	max	reqs	failed	RSS @ 50 VU	Artifact
GraalVM native	158.58ms	172.57ms	178.64ms	374.39ms	15,570	0%	134–154 MB	112 MB binary
Spring Boot jar	156.97ms	171.86ms	177.16ms	287.17ms	15,590	0%	477–949 MB	32 MB jar
Rust (warp + sqlx)	160.89ms	179.45ms	191.91ms	351.72ms	15,545	0%	20–40 MB	21 MB binary

All three runtimes pass both thresholds on the same day, on the same box, against the same database. Rust lands within ~7ms of the JVM’s p(95) — and serves the load from a 21 MB binary topping out at 40 MB RSS, while the JVM pays its heap for the same traffic.

2.1 The bug the load test caught: a `Lazy` regex that compiled per request

The first Rust run was a collapse: avg 757ms, p(95) 952ms, 10k reqs vs 15.5k for Java — and top showed the Rust process eating 623% CPU for 28 req/s. Nothing about the workload explained it, so we profiled the live process (perf record on the server, then the same repro locally with macOS sample).

The call graph said it all:

regex_automata::dfa::determinize ... 596 samples
  once_cell::Lazy::get_or_init
    regex::Regex::new
      mpazari::util::taxonomy_slug
        mpazari::web::home::home

taxonomy_slug declared its regex inside the function :

pub fn taxonomy_slug(s: &str) -> String {
    let x = transliterate(s).to_lowercase();
    let re: Lazy<Regex> = Lazy::new(|| Regex::new("[^a-z0-9]+").unwrap()); // ← per call!
    ...
}

A let re: Lazy<Regex> inside a function is not a cache — it is a fresh Lazy per call, so every invocation re-compiled the regex, lazily building its full DFA. The home page renders ~183 brand slugs + 82 cities + 40 categories plus 39 listing cards — hundreds of regex compilations per request. It looked like a Lazy (static-shaped code), but it was a let, so it behaved like Regex::new on the hot path.

Moving the regex to a module-level static RE_NON_ALNUM: Lazy<Regex>:

	before	after
home page (single request, prod)	170–198ms	30–40ms
k6 50 VUs	avg 757ms, p(95) 952ms	avg 161ms, p(95) 179ms
app CPU under load	623%	18%
regex frames in sample	~12% of samples	0

The lesson generalizes: in Rust, a Lazy is only a cache if it outlives the call. let re = Lazy::new(...) reads like static RE: Lazy<Regex> and compiles silently — unit tests pass, pages render correctly, and only a production load test with a CPU counter exposes it.

The second fix was Java-parity caching, found by reading GlobalModelAdvice: Spring caches brands/cities/categories/counts in memory for 1h and the two footer COUNT(*)s for 10m — the Rust side re-queried brand_hub/city_hub/counts on every request. Porting the same TTLs (TaxonomyCache + a 10-minute CountsCache) brought per-request SQL to ~5 queries, matching the Java home handler.

2.2 Memory: the number the whole rewrite was chasing

The RSS column in the main table comes from the same production box: swap the runtime, restart, run a separate 2.5-minute 50-VU k6 while sampling the process RSS every 15s. Idle values, for completeness:

Runtime	RSS idle
GraalVM native image	~4 MB¹
Spring Boot jar	~477 MB
Rust (warp + sqlx)	19 MB

The JVM pays for its configured heap: run-prod.sh starts it with -Xms1g, so RSS begins near half a gigabyte and climbs toward ~1 GB as pages are touched under load. The native image is impressively compact at boot (~4 MB of resident pages before requests pull code and heap in) but settles around 140 MB serving traffic. Rust idles at 19 MB and tops out at 40 MB — roughly 3.5× less than the native image and 24× less than the JVM , while serving the same 50 VUs within a few ms of both.

6. What we learned

Parity testing is the whole project. A rewrite is not a port; it is a proof. The test harness (31 acceptance + 150 e2e) is the actual deliverable — the Rust code is almost a byproduct of writing it.
Silent emptiness is the enemy. A missing context key renders an empty list, not an error. Every “empty page” report (/markalar, /sehirler, /arama, favorites, the edit form) was a handler-template key mismatch, never a database problem.
Legacy URLs are a product feature. A decade of .aspx links, query-string shapes and redirect quirks live in Java’s LegacyRedirectController. Rust reimplemented the full map — and Playwright tests every row of it.
One binary named the same as the old one makes deploy a copy. Zero ceremony: cp, restart, health sweep, rollback if unhealthy.

From MySQL to PostgreSQL: a much lighter server

özkan pakdil — Fri, 18 Sep 2026 00:00:00 +0000

I recently migrated mpazari.com, a Turkish motorcycle classifieds site, from MySQL 8 to PostgreSQL 12.

The application is a Spring Boot 4 / Java 25 GraalVM native image using hand-written SQL. The migration involved moving the existing database, adapting the MySQL-specific queries, and testing the application against a real production snapshot.

The migration was completed with approximately three minutes of downtime. The main steps were:

Create the PostgreSQL schema.
Copy the MySQL data into PostgreSQL.
Update the application queries for PostgreSQL.
Run the test suite and verify the row counts.
Stop the application, perform the final copy, switch the JDBC URL, and restart it.

PostgreSQL’s stricter typing exposed a few old data and SQL issues that MySQL had silently accepted. The test suite helped find and fix those issues before the production cutover.

The unexpected result

The most interesting result was the server load.

With MySQL, top commonly showed a load average of around 1.5. After switching to PostgreSQL, the same server and application workload usually showed a load average around 0.3-0.5.

That is a significant improvement. The server feels much lighter, even though the database, application, indexes, and hardware are essentially the same.

This is not a formal benchmark. I did not run a controlled performance test or collect latency percentiles before and after the migration. It is simply a real production observation from the server while handling the same site traffic.

The database is relatively small, at about 131 MB, and both databases had the same application workload and indexes. So I cannot claim that PostgreSQL is universally faster than MySQL. For this particular application, however, PostgreSQL uses noticeably less server capacity.

Conclusion

The migration reduced downtime and produced a much calmer server:

MySQL: approximately 1.5 load average
PostgreSQL: approximately 0.3-0.5 load average

The biggest lesson is simple: even when two databases support the same application, their behavior under a real workload can be surprisingly different.

Playwright Resource Monitor: making CI fail when your browser tabs burn CPU

özkan pakdil — Sun, 30 Aug 2026 00:00:00 +0000

Green build, slow pages. That combination has annoyed me for years: Playwright happily reports 136/136 passing while the browser quietly burns 90% of one core on a badly-behaved tab, or the whole runner sits at 99% memory and everything gets suspiciously slow. Test outcomes say nothing about how much resource the tests consumed. Resource waste in CI is exactly the kind of thing you want to fail loudly, not discover from user complaints later.

So I finally built it: playwright-resource-monitor, a GitHub Action that wraps your Playwright run, watches machine-wide CPU/memory and the worst single browser tab, fails the build when configurable thresholds are crossed, and records every run’s peaks in the job summary plus a cross-run history.

What it watches

Two layers, four thresholds, each with its own meaning:

Layer	What it measures	Default
Machine	CPU % across all cores combined , memory % of the effective RAM limit	70 / 70
Tab	The worst single tab (renderer process): CPU as % of one core (yes, it can exceed 100%), memory % of the RAM limit	70 / 70

The per-tab layer is the one I actually care about. A machine-wide average on an 8-core runner looks serene even when one tab is melting. The average dilutes exactly the signal you want. “Worst single renderer process” is the meaningful question: is any page we serve behaving badly?

How it sees your browser (the fun part)

A GitHub Action is a separate process from your test run: it spawns bun run test:e2e (or npm run test) as a child and can’t reach inside Playwright to hook anything. That constraint shaped the whole design. On Linux, the answer is the good old process table:

/proc/<pid>/cmdline finds Chromium processes and classifies them; --type=renderer processes are tabs
/proc/<pid>/stat gives CPU time deltas between polls → the tab’s CPU consumed as % of one core
/proc/<pid>/status + a cgroup-aware limit check gives memory as % of RAM

Zero configuration in your project. No reporter to add, no dependency, nothing. The action also polls for a Chrome DevTools Protocol port if you want exact per-tab labels, and it injects that port for you as an environment variable.

The machine layer is sampled by the action itself too (deltas from /proc/stat, usage from /proc/meminfo, respecting cgroup memory limits for containerized runners). And because the action owns this sampler, machine breaches are logged live during the run as alert groups in the step log, not discovered after the fact:

::start-group::RESOURCE ALERT #1 at 12:03:41 — worst tab: renderer pid 4242
::warning::Threshold breach: tab CPU 96.4% > 70% of one core
::endgroup::

Optional extra: if your project uses monocart-reporter with json: true, the action automatically prefers its report and gets a machine-wide CPU/memory timeline in an HTML report for free. But it’s optional. The built-in sampler covers enforcement on its own.

Using it

      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright install chromium
      - uses: ozkanpakdil/github-playwright-monitor@v1
        with:
          machine-cpu-threshold: 80 # % of all cores combined
          machine-memory-threshold: 70 # % of effective RAM limit
          tab-cpu-threshold: 70 # % of ONE core, worst single tab
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: resource-reports
          path: resource-monitor/

That’s the whole setup. Thresholds are strictly-greater-than, so 70 means “fail if any single tab holds more than 70% of one core”. Set per-tab high (like 300) if you only care about runaway tabs, and keep machine thresholds meaningful for your runner’s size.

Every run appends a record to a history file, rendered into the job summary as a table (newest first, linked to each run):

{
  "outcome": "failed",
  "machine": { "peakCpuPercent": 66.3, "peakMemoryPercent": 99.6, "samples": 45 },
  "tab": { "peakCpuPercent": 84.1, "peakMemoryPercent": 11.2, "samples": 88 },
  "breached": { "machineMemory": true, "tabCpu": false }
}

Runners are ephemeral, so keep the trend across runs with actions/cache:

      - uses: actions/cache@v4
        with:
          path: resource-monitor/history.json
          key: resource-history-${{ github.run_id }}
          restore-keys: resource-history-

The verdict rules

run-command fails → the action fails; the test result is authoritative.
Any threshold breach with fail-on-breach: true (the default) → the action fails naming each breached layer with peaks vs thresholds. With false, it only warns and stays green, which is handy for the first weeks on a new project while you calibrate.
Nothing to monitor (no browser launched, no report) → the action stays silent and green. Wrapping a command that happens to launch no browsers is not an error.

That last one matters more than it sounds: the action just wraps a shell command, and “it did nothing weird to my run” is a hard requirement for a CI gate.

What it taught me about thresholds

I validated the whole loop on my own TrendCast repo (a browser extension with 136 Playwright tests). Machine memory read 99.6% of RAM and tripped the 70% threshold (on my laptop, not the runner). Machine memory % counts the whole host, other apps included, and macOS especially reads high. On a dedicated GitHub runner it’s a healthy signal; on a shared machine, either size the machine thresholds for the runner or use fail-on-breach: false locally. Per-tab numbers don’t have this problem: a tab’s RSS is the tab’s.

Testing before “publishing”

One more thing I care about: you can consume the action by repo reference (owner/repo@main) with no release required. The Marketplace “publish” button only adds the listing (and asks for a tag when you’re ready). The repo’s CI runs a two-leg smoke matrix on every push: a “native” leg (no extra dependencies, asserting the built-in machine sampler and the /proc tab scanner both produce data around a real browser test) and a “monocart” leg. So every push is a pre-release test of both monitoring paths. When it’s green, tag v1, draft a release, tick Publish to the GitHub Marketplace.

Limitations, honestly

The tab layer is Linux-only (process table). On macOS/Windows runners you’d need the CDP opt-in for tabs.
Machine memory on shared hosts reads high (see above).
Parallel CDP mode shares one debug port, so on Linux just use the /proc scanner.
Nothing to monitor → nothing enforced; the pass-through is intentional and quiet.

The code is small and readable: one sampler per data source, ~30 unit tests around the parsing and threshold math. Browse it at github.com/ozkanpakdil/github-playwright-monitor, or look at the TrendCast workflow for a real-world usage. If your green build has ever felt slower than it should, you now have a way to catch the culprit per-tab ,and to make the build fail loudly when a page burns your CI budget.

How to add NVIDIA free models to VS Code

özkan pakdil — Sun, 19 Jul 2026 00:00:00 +0000

NVIDIA offers free access to their powerful Nemotron models through their NVIDIA Build platform. In this post, I'll walk you through how to get a free API key and configure it in VS Code to use models like nvidia/nemotron-3-ultra-550b-a55b directly in VS Code. Also you can choose any other model from here.

Prerequisites

VScode needs to be above 1.27 it needs to have customendpoint supporting

Getting Your Free NVIDIA API Key

Go to build.nvidia.com
Sign in or create an NVIDIA account
Navigate to the model you want to use (e.g., Nemotron 3 Ultra)
Click "Get API Key" button

Note: In my experience, the "Get API Key" button in the UI didn't work properly (it appeared to do nothing). If this happens to you, here's how to get your API key:

Open your browser's Developer Tools (F12) → Network tab
Click the "Get API Key" button again
Look for a POST request to https://api.nvcf.nvidia.com/v2/nvcf/api-keys
Click on that request and check the Response tab - you'll find your API key there

The API call looks like this (for reference - you don't need to run this manually):

# This is what the UI calls behind the scenes - for reference only
curl 'https://api.nvcf.nvidia.com/v2/nvcf/api-keys' \
  -H 'Accept: */*' \
  -H 'Accept-Language: en-GB,en;q=0.9' \
  -H 'Accept-Encoding: gzip, deflate, br, zstd' \
  -H 'Referer: https://build.nvidia.com/' \
  -H 'content-type: application/json' \
  -H 'Origin: https://build.nvidia.com' \
  -H 'Connection: keep-alive' \
  -H 'Cookie: ...' \
  -H 'Sec-Fetch-Dest: empty' \
  -H 'Sec-Fetch-Mode: cors' \
  -H 'Sec-Fetch-Site: same-site' \
  --data-raw '{"name":"","type":"AI_PLAYGROUNDS_KEY","expiryDate":"2027-01-19T11:37:44Z","policies":[{"product":"nv-cloud-functions","scopes":["invoke_function"],"resources":[{"id":"*","type":"account-functions"}]}]}'

The response will contain your API key:

{
  "apiKey": {
    "keyId": "1a9e12d7-b35f-4ed0-943c-3935c442a5c9",
    "name": "NVIDIABuild-Autogen-54",
    "type": "AI_PLAYGROUNDS_KEY",
    "value": "nvapi-...",
    "ownerId": "...",
    "status": "ACTIVE",
    "expiryDate": "2027-01-19T11:37:44.000Z",
    "createdDate": "2026-07-19T11:39:27.197Z",
    "policies": [
      {
        "product": "nv-cloud-functions",
        "productDisplayName": "NVIDIA Cloud Functions",
        "resources": [
          {
            "id": "*",
            "type": "account-functions"
          },
          {
            "id": "*",
            "type": "authorized-functions"
          }
        ],
        "roles": [],
        "scopes": [
          "invoke_function",
          "list_functions",
          "list_functions_details",
          "queue_details"
        ]
      },
      {
        "product": "ai-foundations",
        "productDisplayName": "Public API Endpoints"
      },
      {
        "product": "artifact-catalog",
        "productDisplayName": "NGC Catalog"
      },
      {
        "product": "private-registry",
        "productDisplayName": "NVIDIA Private Registry"
      }
    ]
  }
}

Important: Save the value field (the nvapi-... key) - you'll need it for VS Code configuration.

Configuring VS Code

The recommended way is to use the VS Code UI to add the custom model, which will properly encrypt and store your API key. Custom language models are configured in a separate file called chatLanguageModels.json (not in settings.json under chat.mcp.servers - that's for MCP servers, which is a different feature).

Using VS Code UI

Check the video if you have not done before. Below are the steps

Open VS Code Command Palette (Cmd/Ctrl + Shift + P)
Search for "Chat: Manage Language Models" here the docs
Click "Add Model" or "Add Custom Model"
Fill in the details:
- Name: Nvidia (or any name you prefer)
- Vendor: customendpoint
- API Key: Enter your nvapi-... key (VS Code will encrypt and store it securely)
- Model ID: nvidia/nemotron-3-ultra-550b-a55b
- Model Name: nvidia/nemotron-3-ultra-550b-a55b
- URL: https://integrate.api.nvidia.com/v1/chat/completions
- Tool Calling: ✅ Enabled
- Max Input Tokens: 262144
- Max Output Tokens: 32000

in chatLanguageModels.json will have json like below

[
  {
        "name": "Nvidia",
        "vendor": "customendpoint",
        "apiKey": "${input:chat.lm.secret.6878c97f}",
        "models": [
            {
                "id": "nvidia/nemotron-3-ultra-550b-a55b",
                "name": "nvidia/nemotron-3-ultra-550b-a55b",
                "url": "https://integrate.api.nvidia.com/v1/chat/completions",
                "toolCalling": true,
                "vision": false,
                "maxInputTokens": 262144,
                "maxOutputTokens": 32000
            }
        ]
    }
]

Using the Model in VS Code

Once configured, you can use the model in VS Code Chat:

Open the Chat view (Ctrl+Alt+I / Cmd+Option+I)
Click the model selector dropdown
Select "Nvidia" → "nvidia/nemotron-3-ultra-550b-a55b" (or whatever name you gave the model)
Start chatting!

The model supports:

Tool calling - Can use tools and functions
Vision - Can analyze images
128K context window - Large context for long conversations
16K output tokens - Long responses

Model Details

Property	Value
Model ID	`nvidia/nemotron-3-ultra-550b-a55b`
Endpoint	`https://integrate.api.nvidia.com/v1/chat/completions`
Context Window	128,000 tokens
Max Output	16,000 tokens
Tool Calling	✅ Yes
Vision	✅ Yes
Free Tier	✅ Yes (with NVIDIA account)

Tips

Rate Limits: The free tier has rate limits. Check NVIDIA's documentation for current limits.
API Key Expiry: The key expires on the date shown in the response (e.g., 2027-01-19). You'll need to generate a new one when it expires.
Multiple Models: You can add multiple NVIDIA models to the same configuration by adding more entries to the models array.
VS Code Insiders: If you're on VS Code Insiders, the settings path might be slightly different.

Resources

Happy coding with NVIDIA's free models! 🚀

Beyond Functionality: Why Code Hygiene is Your Project's Immune System

özkan pakdil — Wed, 22 Apr 2026 00:00:00 +0000

In the world of software engineering, we often obsess over the “Testing Pyramid.” We pour resources into unit tests, integration tests, and E2E suites. These are critical—they tell us that our features work as designed. But there’s a shadowy category of bugs that traditional tests often miss: the architectural “anti-patterns” and “API misuses” that don’t break functionality today but lead to system failures, memory leaks, or portability issues tomorrow.

This is where Code Hygiene comes in.

What is Code Hygiene?

Code Hygiene is the practice of using automated tools to enforce non-functional constraints, coding standards, and safety patterns across a codebase. Unlike a unit test that checks if Add(1, 1) == 2, a hygiene scanner checks if you’re using an API in a way that’s technically “valid” but practically dangerous.

In Computer Science, this is formally known as Static Program Analysis. While general “linting” catches stylistic issues, Code Hygiene focuses on domain-specific safety and architectural integrity.

The Evolution: From API Safety to Platform Portability

One of the most powerful applications of code hygiene I’ve ever implemented involved managing a high-stakes support matrix. We had a system that executed various Linux commands across a wide range of distributions: Ubuntu, SUSE, and RedHat, all in different versions.

The Problem: The Command Parameter Minefield

As Linux distributions evolve, command-line parameters change. A flag that works on Ubuntu 20.04 might be deprecated on RedHat 9, or worse, behave subtly differently. Standard CI runs on a single OS wouldn’t catch these issues until a customer on a specific RedHat version hit a runtime error.

The Solution: Static Analysis + Testcontainers

To solve this, I developed a two-tier hygiene strategy:

The Scanner: We built a custom static analysis tool to crawl through the codebase and identify every single exec or shell-out call.
The Matrix Validation: Using Testcontainers with C# , we spun up the exact versions of Ubuntu, SUSE, and RedHat defined in our support matrix. We then fed the commands discovered by our scanner into these containers to verify their exit codes and behavior.

This “Hygiene for Portability” transformed our release process. We stopped guessing if our commands were compatible and started knowing.

Case Study: The “Order of Operations” Leak

Hygiene isn’t just for external commands; it’s for internal APIs too. Recently, I dealt with a scenario where a database library had a specific requirement: BeginTransaction() had to be called after certain context configurations, but before others.

Syntactically, the code db.WithContext(ctx).Begin() looked fine. It compiled. It even passed unit tests. However, in tests, it caused intermittent memory leaks because the context wasn’t being associated with the transaction object correctly.

A simple AST (Abstract Syntax Tree) scanner fixed this permanently. We wrote a rule that flags any instance where these calls are out of order. Institutional knowledge was turned into an automated gatekeeper.

Why You Need a Hygiene Strategy

Preventing “Silent” Failures: Catch memory leaks, race conditions, and API misuses that don’t trigger a test failure but kill performance.
Institutional Memory: When a team learns a hard lesson, a hygiene rule ensures that new developers (or your future self) don’t repeat the mistake.
Scalable Reviews: Humans are bad at spotting subtle pattern errors in 1,000-line PRs. Computers are perfect at it.
Platform Confidence: In a world of multi-arch and multi-OS support, scanners can validate that your code respects the constraints of every target environment.

Conclusion

Testing tells you the code is right. Hygiene tells you the code is healthy.

By integrating custom static analysis and matrix-based validation into your workflow, you move from a reactive “hotfix” stance to a proactive “preventative” culture. It’s time to look beyond functionality and start caring about the structural health of your codebase.

Accelerating LLMs on Debian 13: Setting up Vulkan for llama.cpp

özkan pakdil — Sun, 22 Mar 2026 06:47:00 +0000

After setting up CUDA on my other laptop, I moved to a different(older) machine that doesn’t have an NVIDIA GPU. This one is an everyday laptop with integrated Intel graphics, but that doesn’t mean we have to settle for slow CPU-only performance.

On this machine, I switched to the Vulkan backend for llama.cpp and the results were even more dramatic than I expected.

Machine Hardware Info

This laptop is running Debian 13 (Trixie/Sid) with the following specs:

CPU : Intel(R) Core(TM) i5-8250U @ 1.60GHz (4 Cores, 8 Threads)
GPU : Intel(R) UHD Graphics 620 (Integrated)
RAM : 8 GB
OS : Debian GNU/Linux 13 (trixie)
Kernel : 6.12.74+deb13+1-amd64

The Performance Gap: CPU vs. Vulkan

I tested both the Qwen 3.5 2B and the more capable Qwen 2.5 3B models (GGUF format) to see how the integrated Intel GPU handles different LLM sizes.

Model	Setup	Response Time (Eval)	Total Time	Tokens/sec	Notes
Qwen 3.5 2B	CPU Only	~7 minutes (428s)	431s	2.32	Purely on i5-8250U
Qwen 3.5 2B	Vulkan	14 seconds	21s	6.07	30x improvement!
Qwen 2.5 3B	Vulkan	47 seconds	52s	4.54	More capable reasoning

The 14-second response vs. 7 minutes on the 2B model is a game-changer, but the 3B model (answering “write me hello world in rust” in 47 seconds ) is the “sweet spot” for this machine. While the 2B model can be fully offloaded, the 3B model is too large to fit entirely in the GPU’s shared memory, but it still performs admirably.

Compiling llama.cpp with Vulkan

Compiling for Vulkan on Debian is straightforward but requires the right development headers. It took me about 10 minutes to finish the compilation.

First, ensure you have the Vulkan development packages:

sudo apt update
sudo apt install libvulkan-dev vulkan-tools

Then, compile llama.cpp using CMake with the Vulkan option enabled:

cmake -B build -DGGML_VULKAN=ON
cmake --build build --config Release

Running with Vulkan Acceleration

Once compiled, you can run llama-server (or llama-cli). The server will automatically detect your Vulkan-compatible devices.

./build/bin/llama-server -hf unsloth/Qwen3.5-2B-GGUF --jinja -c 4096 --host 127.0.0.1 --port 8033

In the logs, you’ll see it picking up the Intel UHD Graphics. For the 2B model, I was able to offload all 25 layers:

ggml_vulkan: Found 1 Vulkan devices:
ggml_vulkan: 0 = Intel(R) UHD Graphics 620 (KBL GT2) (Intel open-source Mesa driver) | uma: 1 | fp16: 1 | ...
...
load_tensors: offloading 23 repeating layers to GPU
load_tensors: offloaded 25/25 layers to GPU

Pushing the Limits: Qwen 2.5 3B

When I moved to the 3.4B parameter model (Qwen2.5-3B-Instruct-Q4_K_M), the memory management became more complex. The system had to balance between the GPU’s shared memory and the CPU:

llama_params_fit_impl: projected to use 2283 MiB of device memory vs. 2200 MiB of free device memory
llama_params_fit_impl: cannot meet free memory target of 1024 MiB, need to reduce device memory by 1106 MiB
llama_params_fit_impl: filling dense layers back-to-front:
llama_params_fit_impl: - Vulkan0 (Intel(R) UHD Graphics 620 (KBL GT2)): 13 layers, 1137 MiB used, 1062 MiB free
...
load_tensors: offloaded 13/37 layers to GPU

Even though it only offloaded 13/37 layers to the GPU, it still maintained a respectable 4.54 tokens/sec. This shows that even partial offloading on integrated graphics provides a significant boost over pure CPU execution for larger models.

Summary & Next Steps

If you don’t have an NVIDIA card, don’t ignore your integrated GPU. Vulkan provides a fantastic alternative that works out-of-the-box on Debian with Intel and AMD hardware.

My next target is to use Qwen on OpenClaw to further explore local LLM capabilities. Stay tuned!

Accelerating LLMs on Debian 13: Setting up CUDA for llama.cpp

özkan pakdil — Thu, 19 Mar 2026 22:35:00 +0000

Setting up NVIDIA CUDA on Debian 13 (Trixie/Sid) to run Large Language Models (LLMs) can be a bit of a journey, especially if you’re transitioning from the default open-source drivers to the proprietary stack required for GPGPU workloads.

Over the last few days, I’ve been working on getting llama.cpp to run with CUDA on my laptop to see how much of a difference it makes compared to pure CPU execution.

Initially, I tested a 35B model on macOS , where it was responding in about 17 seconds. When I moved that same 35B model to my old laptop running Debian 13 (on CPU), the response time plummeted to 4 minutes and 30 seconds. This massive gap was my main motivation to try and enable CUDA on the laptop’s GPU.

The Problem: Nouveau vs. Proprietary Drivers

By default, Debian might use the open-source nouveau driver. While great for basic display tasks, it doesn’t support CUDA. To run llama-server with GPU acceleration, you need the official NVIDIA drivers and the CUDA toolkit.

I followed the NVIDIA Tesla Driver Installation Guide for Debian, which is a critical resource for getting the right packages.

One specific hurdle with Secure Boot enabled was the need to trust the DKMS-generated keys:

sudo mokutil --import /var/lib/dkms/mok.pub

After a reboot and enrolling the key in the MOK manager, the driver was finally active and recognized by the system.

Compiling llama.cpp with CUDA Support

Once the drivers and nvcc were ready, I recompiled llama.cpp with CUDA enabled (see the official CUDA build documentation for more details).

The compilation process is quite resource-intensive and took about 15 minutes on my laptop:

export CUDACXX=/usr/local/cuda/bin/nvcc
export CUDA_HOME=/usr/local/cuda
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release

The VRAM Reality Check (OOM Errors)

My laptop has an NVIDIA GeForce MX450 with 2 GB of VRAM. This is quite modest for modern LLMs.

Initially, I tried running that 35B model that was so slow on the CPU:

llama-server -hf unsloth/Qwen3.5-35B-A3B-GGUF --jinja -c 16384 --host 127.0.0.1 --port 8033

It failed with a cudaMalloc failed: out of memory error. Looking at the logs:

Model parameters: ~857 MiB
Context/CLIP buffers: ~899 MiB
Total requested: > 1.7 GB

With the OS and display driver already taking up some of that 2 GB, there just wasn’t enough room. The 35B model was simply too large for this specific hardware’s VRAM. Even though CUDA would have been faster than the CPU-only 4.5 minutes, the hardware limit forced me to pivot.

The Result: 2B Model Benchmark

I switched to a smaller 2B model to stay within the VRAM limits. The results were impressive and clearly showed why we go through this trouble.

Asking Qwen 2B to “write me hello world in rust” :

Setup	Time to Complete
CPU Only	1 minute 32 seconds
CUDA (GPU)	24 seconds

That’s nearly a 4x speed improvement on a entry-level mobile GPU!

Summary

While the setup can be “so complicated” (dealing with drivers, Secure Boot, and compilation), the performance gains are undeniable. Even on a low-end GPU like the MX450, offloading the heavy lifting to CUDA makes the local LLM experience much more interactive.

Bonus: NVIDIA GPU Diagnostic Script

To help troubleshoot my setup, I wrote a small script nvidia_check_and_run.sh to verify the driver, kernel modules, and llama.cpp support.

#!/bin/bash

# Configuration
LLAMA_PATH="/nix/store/wr7vi3957cx751la7q490h9v2m6q71fm-llama-cpp-8255/bin"
LLAMA_SERVER="$LLAMA_PATH/llama-server"
LLAMA_BENCH="$LLAMA_PATH/llama-bench"
LLAMA_CLI="$LLAMA_PATH/llama-cli"

echo "--- NVIDIA GPU Diagnostic ---"

# 1. Check for the NVIDIA device via PCI
echo "[1/4] Checking PCI devices for NVIDIA GPU..."
if lspci | grep -i nvidia; then
    echo " - NVIDIA hardware detected via lspci."
else
    echo " - No NVIDIA hardware found on PCI bus."
fi

# 2. Check for the driver status
echo -e "\n[2/4] Checking NVIDIA driver status..."
if command -v nvidia-smi &> /dev/null; then
    echo " - nvidia-smi found. Running..."
    if ! nvidia-smi; then
        echo " - CRITICAL: nvidia-smi failed. Kernel modules might not be loaded."
        echo " - ACTION: Try running 'sudo modprobe nvidia' and then 'nvidia-smi' again."
    fi
else
    echo " - nvidia-smi NOT found. Driver might not be installed or active."
fi

# 3. Check for the kernel modules
echo -e "\n[3/4] Checking for loaded NVIDIA kernel modules..."
if /sbin/lsmod | grep -i nvidia &> /dev/null; then
    echo " - NVIDIA kernel modules are loaded."
    /sbin/lsmod | grep -i nvidia
else
    echo " - CRITICAL: No NVIDIA kernel modules loaded."
    echo " - ACTION: Run 'sudo modprobe nvidia' to load the driver."
fi

# 4. Check for llama.cpp device support
echo -e "\n[4/4] Checking llama.cpp device support..."
if [-f "$LLAMA_CLI"]; then
    echo " - Checking llama-cli with -ngl flag..."
    "$LLAMA_CLI" -ngl 1 --version
else
    echo " - llama-cli not found at $LLAMA_CLI"
fi

Running this script gave me a clear picture of what was missing:

--- NVIDIA GPU Diagnostic ---
[1/4] Checking PCI devices for NVIDIA GPU...
0000:01:00.0 3D controller: NVIDIA Corporation TU117M [GeForce MX450] (rev a1)
  - NVIDIA hardware detected via lspci.

[2/4] Checking NVIDIA driver status...
  - nvidia-smi found. Running...
Fri Mar 20 01:55:51 2026       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 595.45.04 Driver Version: 595.45.04 CUDA Version: 13.2 |
+-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce MX450 On | 00000000:01:00.0 Off | N/A |
| N/A 53C P8 N/A / 5001W | 5MiB / 2048MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+

[3/4] Checking for loaded NVIDIA kernel modules...
  - NVIDIA kernel modules are loaded.
...
[4/4] Checking llama.cpp device support...
  - Checking llama-cli with -ngl flag...
warning: no usable GPU found, --gpu-layers option will be ignored
warning: one possible reason is that llama.cpp was compiled without GPU support
...

If you are on Debian 13 and want to try this, make sure you check your VRAM limits before picking a model, and don’t forget that mokutil step if you have Secure Boot enabled!

Tuning Podman on macOS to Match OrbStack Performance

özkan pakdil — Sun, 08 Mar 2026 19:02:00 +0000

Note: These are suggested optimizations I have not personally tried yet. I’m blogging them as I’m planning to test them throughout this week.

OrbStack is highly optimized for macOS, using a proprietary, high-performance networking stack and a custom VirtioFS implementation with aggressive caching. Podman, while being open-source and standard-compliant, can be tuned to significantly bridge the performance gap.

The following plan outlines key areas where Podman’s performance can be improved on macOS:

1. Enable Rosetta 2 for x86_64 Emulation (Apple Silicon only)

If you are on an Apple Silicon (M1/M2/M3/M4) Mac, running x86_64 containers is often much slower than ARM64. Podman supports Apple’s native Rosetta 2 for Linux, which is substantially faster than QEMU-based emulation.

Check if Rosetta is enabled: Run podman machine inspect and look for "Rosetta": true.
Enable Rosetta: When creating a new machine, use the --rosetta flag (if your Podman version and macOS version support it, typically macOS 13+):

podman machine init --rosetta

Note: If you have an existing machine, you may need to recreate it to enable Rosetta.

2. Optimize Volume Mounting (VirtioFS)

Podman uses virtiofs by default on macOS, which is the fastest way to share files between the host and the VM using Apple’s Virtualization.framework. However, file system I/O can still be a bottleneck.

Avoid Deeply Nested Mounts: Minimize the number of files synced by mounting only the necessary sub-directories instead of the entire home directory.
Use Named Volumes: For high-I/O workloads (like database storage or node_modules), use named volumes instead of bind mounts. Named volumes reside within the VM’s disk image and operate at near-native speeds.

podman volume create my-data
podman run -v my-data:/app/data ...

3. Tuning Resource Allocation

Ensure the Podman machine has sufficient resources. The default settings might be conservative for demanding workloads.

Increase CPUs and Memory: Adjust the machine’s resources to match your workload.

podman machine set --cpus 4 --memory 8192

(Requires the machine to be stopped: podman machine stop)

4. Networking Performance (gvproxy)

Podman uses gvproxy for user-mode networking. This is often the primary reason OrbStack feels faster for network-heavy tasks, as OrbStack uses a more direct networking approach.

Reduce Network Hops: If possible, avoid complex port mappings or heavy network traffic through the user-mode proxy.
MTU Tuning: In some environments, increasing the MTU within the container can improve throughput, though this is dependent on the host’s network configuration.

5. Experiment with the `libkrun` Provider

Podman on macOS supports multiple virtualization backends. While applehv (default) is stable, libkrun (based on krun) can sometimes offer better performance for specific workloads, especially those involving GPU acceleration or specialized Virtio devices.

Try libkrun: You can initialize a machine with the libkrun provider:

podman machine init --provider libkrun

6. Summary of Recommended Configuration for Speed

To get the best performance today, use the following initialization command (on Apple Silicon):

# Stop and remove existing machine if necessary
podman machine stop
podman machine rm

# Initialize with optimized settings
podman machine init \
  --cpus 4 \
  --memory 8192 \
  --disk-size 50 \
  --rosetta \
  --rootful=false

By applying these optimizations, Podman’s performance on macOS will be significantly closer to OrbStack, especially for CPU-intensive emulation and file-system heavy development workflows.

Happy containerizing!

Atlassian MCP

özkan pakdil — Sun, 08 Feb 2026 00:00:00 +0000

I have been using Atlassian MCP with internal Confluence and Jira, and it has been wonderful.

Finding internal information is often challenging and time-consuming. To be honest, searching through Jira or Confluence and locating the right information can be really difficult.

Create Jira and Confluence API tokens from your internal site profile page. For example: https://internalconfluence.company.com/profile/personal for Confluence and https://jira.company.com/secure/admin/CreateAPIToken!default.jspa for Jira. These URLs may vary depending on your setup.
Create an mcp.json file in the .vscode folder for Visual Studio Code, or place this MCP configuration in the appropriate folder for your IDE of choice:

{
  "mcpServers": {
    "mcp-atlassian": {
      "command": "uvx",
      "args": ["mcp-atlassian"],
      "env": {
        "JIRA_URL": "https://jira.company.com",
        "JIRA_USERNAME": "your.email@company.com",
        "JIRA_API_TOKEN": "your_api_token",
        "CONFLUENCE_URL": "https://internalconfluence.company.com/wiki",
        "CONFLUENCE_USERNAME": "your.email@company.com",
        "CONFLUENCE_API_TOKEN": "your_api_token"
      }
    }
  }
}

Remember to run podman-desktop or docker desktop. Because this MCP works as a docker container.

After that, open GitHub Copilot in your IDE and instruct it to use the Atlassian MCP to search Confluence and Jira. This makes finding internal information incredibly easy—it goes through pages systematically and retrieves all the details you need.

Building a Real-time File I/O Heatmap with eBPF and Java 25

özkan pakdil — Wed, 21 Jan 2026 05:52:00 +0000

Have you ever wondered exactly which files are being hammered by your Linux system in real-time? While tools like iotop or lsof are great, sometimes you want something more visual, custom, and lightweight.

In this post, I’ll walk you through how I built a Real-time File I/O Heatmap using the power of eBPF for data collection and Java 25 for a modern Terminal UI (TUI).

What is eBPF and Why Use It?

eBPF (Extended Berkeley Packet Filter) is a revolutionary technology that allows you to run sandboxed programs in the Linux kernel without changing kernel source code or loading kernel modules.

Think of it as JavaScript for the Kernel. It allows you to:

Observe : Attach to almost any function in the kernel (kprobes) or userspace (uprobes).
Filter : Process data efficiently at the source, inside the kernel.
Perform : It’s extremely fast because it avoids expensive context switches between kernel and userspace for every event.

For this project, we use eBPF to hook into vfs_read and vfs_write, the gatekeepers of all filesystem activity in Linux.

If you want to dive deeper into eBPF, I highly recommend reading Learning eBPF by Liz Rice, it’s an excellent resource.

The Architecture

Our project consists of three main layers:

The eBPF Program (C): Sits in the kernel, intercepts VFS calls, and aggregates stats (reads, writes, bytes) into a BPF Hash Map.
The Java Backend (Java 25 + JNA): Uses libbpf via Java Native Access (JNA) to load the BPF program into the kernel and poll the maps.
The TUI (Lanterna): A Terminal User Interface that renders the data as a color-coded heatmap.

1. The Kernel Side: eBPF in C

We use BPF CO-RE (Compile Once – Run Everywhere) to ensure our program works across different kernel versions without recompilation.

SEC("kprobe/vfs_read")
int BPF_KPROBE(vfs_read, struct file *file, char *buf, size_t count) {
    // Extract filename from the file struct
    // Filter out non-file noise (sockets/pipes)
    // Update the BPF map with bytes read
    return 0;
}

The magic happens in file_heatmap.bpf.c, where we traverse the kernel’s dentry structures to reconstruct partial file paths so we can actually see what is being accessed.

2. The Bridge: JNA and libbpf

Interfacing Java with the kernel might sound scary, but libbpf makes it manageable. We defined a JNA interface to map the C functions:

public interface LibBpf extends Library {
    Pointer bpf_object__open(String path);
    int bpf_object__load(Pointer obj);
    int bpf_map_lookup_elem(int fd, Pointer key, Pointer value);
    // ...
}

This allows our Java app to behave like a first-class Linux observability tool.

3. The Frontend: A Terminal Heatmap

Using the Lanterna library, we created a TUI that updates every 2 seconds. The heatmap effect is achieved by calculating the “intensity” of I/O for each file and mapping it to a color gradient from white to red.

float intensity = (float) currentVal / maxVal;
int green = (int) (255 * (1 - intensity));
int blue = (int) (255 * (1 - intensity));
tg.setBackgroundColor(new TextColor.RGB(255, green, blue));

Challenges Overcome

Building this wasn’t without its hurdles:

SDKMAN & Sudo : BPF requires root privileges, but sudo often strips the environment variables (like JAVA_HOME) set by SDKMAN. I solved this in the Makefile by using absolute paths and passing environment variables explicitly.
BPF Verifier : The kernel is very strict. Reconstructing file paths required careful use of bpf_probe_read_kernel_str and bpf_snprintf to keep the verifier happy.
vmlinux.h Size : The standard vmlinux.h is over 2MB. I optimized this by using bpftool gen min_core_btf to generate a minified header (~2KB) containing only the types we actually use.
Noise Filtering : Initially, the heatmap was flooded with TCP/UDP socket activity. Adding a filter for S_IFREG (regular files) made the output much cleaner.

How to Run It

You can find the full source code for this project on GitHub: ozkanpakdil/java-examples/ebpf-file-heatmap

If you’re on a Linux machine with clang, bpftool, and maven installed, you can try it out:

git clone https://github.com/ozkanpakdil/java-examples.git
cd java-examples/ebpf-file-heatmap
sudo make run

Once it’s running, you can press 1-5 to sort by different metrics (Reads, Writes, Bytes) and watch your system’s I/O come to life!

Conclusion

Combining eBPF’s low-level performance with Java’s high-level productivity (and the latest features in Java 25!) is a powerful way to build Linux tooling. Whether you’re debugging a database or just curious about what your IDE is doing in the background, this heatmap gives you a unique window into your system.

Happy hacking!

Bun Joins the Microservice Framework Benchmark: Surprisingly Fast JavaScript Runtime

özkan pakdil — Sat, 10 Jan 2026 17:00:00 +0000

Introduction

Today I’m excited to announce the addition of Bun to our microservice framework benchmark suite. The results are nothing short of remarkable . Bun has proven to be one of the fastest runtimes in our entire test suite, competing directly with Rust frameworks!

What is Bun?

Bun is a modern JavaScript runtime built from scratch using Zig and JavaScriptCore (the engine that powers Safari). It’s designed to be a drop-in replacement for Node.js with a focus on:

Speed - Native code execution and optimized I/O
TypeScript support - First-class TypeScript without transpilation
All-in-one toolkit - Runtime, bundler, test runner, and package manager

Implementation Details

Bun Version: 1.3.5

The implementation uses Bun’s native HTTP server API, which is incredibly simple and performant:

const port = 8080;

const server = Bun.serve({
    port: port,
    fetch(req) {
        const url = new URL(req.url);

        if (url.pathname === "/hello") {
            const info = {
                name: "bun",
                releaseYear: new Date().getFullYear()
            };
            return new Response(JSON.stringify(info), {
                headers: { "Content-Type": "application/json" }
            });
        }

        return new Response("Not Found", { status: 404 });
    }
});

console.log(`Bun server started on port ${server.port}`);

The build process is straightforward . Bun can compile TypeScript directly to a standalone executable:

bun build --compile ./main.ts --outfile bun-demo

Benchmark Results: The Numbers Speak

Here are the complete benchmark results for Bun:

---- Global Information --------------------------------------------------------
> request count 32000 (OK=32000 KO=0 )
> min response time 0 (OK=0 KO=- )
> max response time 569 (OK=569 KO=- )
> mean response time 157 (OK=157 KO=- )
> std deviation 115 (OK=115 KO=- )
> response time 50th percentile 148 (OK=148 KO=- )
> response time 75th percentile 208 (OK=208 KO=- )
> response time 95th percentile 403 (OK=402 KO=- )
> response time 99th percentile 483 (OK=483 KO=- )
> mean requests/sec 6400 (OK=6400 KO=- )

Key highlights:

157ms mean response time : faster than Golang (227ms), .NET 9 AOT (255ms), and all JVM frameworks
6,400 requests/sec : matching the throughput of Rust frameworks
0 failed requests : 100% success rate under load (unlike Express.js which had 75% failure rate)
569ms max response time : excellent consistency

Performance Comparison

Let’s put Bun’s performance in perspective with the top performers:

Rank	Technology	Mean Response Time (ms)	Requests/sec
1	Rust (Warp)	144	6,400
2	Rust (Actix)	154	6,400
3	Rust (Axum)	154	6,400
4	Bun	157	6,400
5	Rust (Rocket)	238	5,333
6	Golang	227	5,333
7	.NET 9 AOT	255	5,333
8	.NET 7 AOT	284	5,333
9	.NET 8 AOT	285	5,333
10	GraalVM Micronaut	339	5,333

Bun vs Express.js: A JavaScript Runtime Showdown

The comparison between Bun and Express.js (Node.js) is particularly striking:

Metric	Bun	Express.js (Node.js)
Mean Response Time	157ms	815ms (3,247ms for OK requests)
Requests/sec	6,400	667 (successful only)
Failed Requests	0	24,000 (75% failure rate)
Max Response Time	569ms	10,719ms

Bun is approximately 5x faster than Express.js in mean response time and handles ~10x more successful requests per second. Most importantly, Bun maintained 100% stability under load while Express.js struggled significantly.

Why is Bun So Fast?

Several factors contribute to Bun’s impressive performance:

JavaScriptCore Engine : Safari’s JS engine is highly optimized and often outperforms V8 in certain workloads
Zig Implementation : Low-level systems language with minimal overhead
Native HTTP Server : Built-in server implementation bypasses the overhead of frameworks like Express
Optimized I/O : Uses io_uring on Linux for efficient async I/O operations
No Transpilation Overhead : Native TypeScript execution

Updated Performance Tiers

With Bun’s addition, our performance tiers now look like this:

Performance Tiers:

🥇 TIER 1 (< 200ms): Rust frameworks, Bun
   - Native compilation or highly optimized runtimes
   - Minimal overhead, maximum throughput

🥈 TIER 2 (200-300ms): Golang, .NET AOT, GraalVM Native
   - Excellent performance with broader ecosystem

🥉 TIER 3 (300-600ms): GraalVM Java frameworks
   - Native compilation benefits for JVM

🏅 TIER 4 (> 600ms): JVM frameworks, Node.js/Express.js
   - Full-featured but with more overhead

Conclusion

Bun’s benchmark results are genuinely surprising. A JavaScript/TypeScript runtime competing with Rust frameworks was not something I expected to see. Here are the key takeaways:

Bun is production-ready for high-performance workloads : The 157ms mean response time and 0% failure rate prove it can handle serious traffic.
JavaScript doesn’t have to be slow : Bun demonstrates that with the right architecture, JavaScript can achieve near-native performance.
Consider Bun for new projects : If you’re starting a new microservice and your team knows JavaScript/TypeScript, Bun offers an excellent balance of developer experience and performance.
The gap between Bun and Node.js is massive : If you’re currently using Express.js and need better performance, Bun is worth serious consideration.

For the complete benchmark results including all frameworks, GraalVM native builds, and detailed statistics, check out the full benchmark report.

Source code for tests 👈 Rust examples 👈

DEV Community: özkan pakdil

MariaDB vs MySQL vs PostgreSQL: an mpazari Benchmark

The application

Test setup

Main benchmark

A smaller CPU comparison

Memory and performance_schema

What this does and does not prove

Conclusion

From Spring Boot to Rust: Rewriting a Live Marketplace

From Spring Boot to Rust: Rewriting a Live Marketplace

1. Why, and what exactly

2. The load test: same box, three runtimes

2.1 The bug the load test caught: a Lazy regex that compiled per request

2.2 Memory: the number the whole rewrite was chasing

6. What we learned

From MySQL to PostgreSQL: a much lighter server

The unexpected result

Conclusion

Playwright Resource Monitor: making CI fail when your browser tabs burn CPU

What it watches

How it sees your browser (the fun part)

Using it

The verdict rules

What it taught me about thresholds

Testing before “publishing”

Limitations, honestly

How to add NVIDIA free models to VS Code

Prerequisites

Getting Your Free NVIDIA API Key

Configuring VS Code

Using VS Code UI

Using the Model in VS Code

Model Details

Tips

Resources

Beyond Functionality: Why Code Hygiene is Your Project's Immune System

What is Code Hygiene?

The Evolution: From API Safety to Platform Portability

The Problem: The Command Parameter Minefield

The Solution: Static Analysis + Testcontainers

Case Study: The “Order of Operations” Leak

Why You Need a Hygiene Strategy

Conclusion

Accelerating LLMs on Debian 13: Setting up Vulkan for llama.cpp

Machine Hardware Info

The Performance Gap: CPU vs. Vulkan

Compiling llama.cpp with Vulkan

Running with Vulkan Acceleration

Pushing the Limits: Qwen 2.5 3B

Summary & Next Steps

Accelerating LLMs on Debian 13: Setting up CUDA for llama.cpp

The Problem: Nouveau vs. Proprietary Drivers

Compiling llama.cpp with CUDA Support

The VRAM Reality Check (OOM Errors)

The Result: 2B Model Benchmark

Summary

Bonus: NVIDIA GPU Diagnostic Script

Tuning Podman on macOS to Match OrbStack Performance

1. Enable Rosetta 2 for x86_64 Emulation (Apple Silicon only)

2. Optimize Volume Mounting (VirtioFS)

3. Tuning Resource Allocation

4. Networking Performance (gvproxy)

5. Experiment with the libkrun Provider

6. Summary of Recommended Configuration for Speed

Atlassian MCP

Building a Real-time File I/O Heatmap with eBPF and Java 25

What is eBPF and Why Use It?

The Architecture

1. The Kernel Side: eBPF in C

2. The Bridge: JNA and libbpf

3. The Frontend: A Terminal Heatmap

Challenges Overcome

How to Run It

Conclusion

Bun Joins the Microservice Framework Benchmark: Surprisingly Fast JavaScript Runtime

Introduction

What is Bun?

Implementation Details

Benchmark Results: The Numbers Speak

Memory and `performance_schema`

2.1 The bug the load test caught: a `Lazy` regex that compiled per request

5. Experiment with the `libkrun` Provider