A collection of experiments from PVRLabs.
Original code, scripts, documentation, and experiment artifacts in this repository are licensed under the MIT License, unless otherwise noted. Third-party material retains its original license. Articles and other content linked outside this repository are not covered by this license.
Have an experiment idea or a question? Join the discussions →
Many of our experiments focus on developers building small, self-hosted applications on affordable servers. Think independent developers, solopreneurs, and small teams who want practical software without maintaining complex infrastructure.
For Java applications, we're particularly interested in:
- 256–512 MiB VPS deployments, sometimes extending to 1 GiB.
- Conventional JVM applications using familiar development and diagnostic tools.
- Useful applications with persistence, monitoring, and enough memory headroom for the operating system.
- Maintainable architectures that can grow, including moving a database or other components to separate infrastructure later.
We're not trying to achieve the smallest possible Java process. GraalVM Native Image can offer substantial startup and memory benefits, but it introduces different build, compatibility, and operational tradeoffs. For now, we're more interested in what ordinary HotSpot deployments can accomplish on modest hardware.
Similarly, Kubernetes optimization, container density, and extreme memory minimization aren't our primary focus.
This describes our interests, not strict requirements. The repository also contains experiments outside this area, and we'll continue exploring other technologies when the questions are interesting.
Technical criticism and questions are welcome. See my discussion policy for how I participate in conversations about this work.
We favor simple, reproducible configurations that developers can readily adopt: mainstream frameworks and libraries, recommended defaults, and straightforward, documented optimizations. Ordinary configuration needed to fit the deployment environment is part of that approach.
We keep tuning effort comparable across implementations and avoid fine-grained, workload-specific tuning solely to improve benchmark results. The goal is to inform practical technology and configuration choices, rather than establish each technology's performance ceiling. When specialized tuning could materially change a conclusion, we acknowledge that limitation.
-
Monitoring applications behind Caddy without instrumenting them · October 2026
Express and Spring Boot behind one Caddy reverse proxy, with HTTP monitoring that requires no application changes. A controlled workload shows per-host HTTP errors, latency and recovery, with selected dashboards, inspectable evidence and reproduction scripts.
-
Jdbi, MyBatis and jOOQ in 512 MiB · October 2026
Two unmonitored runs per library with swap disabled, plus a separately selected MyBatis/StatLite follow-up. Includes measured sources, raw OS/HTTP evidence, repeatability checks, dependency inventory, screenshots and reproduction tools.
-
MyBatis, jOOQ, and Jdbi on 256 MiB · October 2026
Three Javalin persistence implementations with file-backed H2 and monitoring. Includes measured source, the separate jOOQ fixture correction, original OS/HTTP evidence, dependency and code inventories, and reproduction instructions.
-
Javalin with JDBC and monitoring on 256 MiB · October 2026
Equivalent Javalin and extracted Spring Boot applications on a constrained Alpine VM, with file-backed H2 and StatLite. Includes original OS/HTTP samples, corrected analyses, screenshots and reproduction code, with paging caveats.
-
Monitoring Javalin with its existing Micrometer instrumentation · October 2026
A small application-side adapter connects Javalin metrics to StatLite for requests, errors, latency, JVM resources, health, and restart history.
-
Monitoring a Pyronaut app with StatLite · October 2026
A Pyronaut Python HTTP app exposed Micronaut/Micrometer Prometheus metrics accepted by released StatLite's existing Micronaut target, with no StatLite changes.
-
Idle PostgreSQL connections and Spring Boot's fixed pool · October 2026
Two Spring Boot instances either kept 20 PostgreSQL connections after a burst or returned to 2. With 2 connections, PostgreSQL cgroup memory was about 29 MiB lower than with 20. Hikari's default pool sizing keeps the peak because its idle target resolves equal to its maximum. Setting a lower idle target released connections only when idle retirement was enabled.
-
Spring Boot, Quarkus, and Micronaut with JDBC · October 2026
Equivalent JDBC applications on Java 25 in a 1 GiB no-swap VM, with sequential 15-minute scripted-load windows and a separate shared-host observation. Includes curated RSS/CPU data, screenshots, source, and analysis.
-
Spring Boot Stars: JPA versus JDBC · September 2026
A paired JDK 25 comparison of the conventional Hibernate Stars app and a smaller Spring MVC + JDBC version. Both expose Actuator for StatLite 0.5.0; raw RSS and startup measurements and reproduction scripts are included.
-
Spring Boot fat JAR vs extracted layout · September 2026
A controlled comparison of Spring Boot's executable fat JAR and its official extracted runtime layout, measuring startup, first-request latency, and settled memory behavior.
-
Spring Boot fat JAR vs extracted layout vs Gradle application distribution · September 2026
A short three-way follow-up using the same application and constrained VM, focused on startup and first-request latency.
-
StatLite on a 256 MB TierHive VPS · September 2026
A manual deployment check of StatLite's native Alpine/OpenRC TierHive recipe, monitoring a Spring Boot Actuator application plus the VPS itself through StatLite self-monitoring.
-
Spring Boot vs Quarkus under extreme memory pressure · September 2026
A curated Spring Boot and Quarkus comparison using the same JDK 25,
Xmx80mprofile, and 512 MiB VM. Quarkus started larger but developed the smaller resident working set under pressure; a later constrained-VM run OOM-killed Spring, showing that the configuration could not reliably keep both JVM applications alive for an hour. -
Spring Boot on a low-memory VPS · August 2026
This experiment tested whether StatLite could provide useful monitoring beside a representative Spring Boot application on a severely constrained VPS. It found that 256 MB RAM was unstable for the application, while at 512 MB RAM with a modest swapfile StatLite remained small and healthy and the controlled observation completed cleanly.