Optimizing PocketBase on a $2 VPS: Achieving 30,000+ Requests Per Second for a Single-File Backend
Introduction
In the modern software development landscape, the trend toward microservices and complex distributed architectures often leads to over-engineering. For many startups, minimum viable products (MVPs), and internal business tools, a simpler approach is not only faster to develop but also significantly cheaper to maintain. Enter PocketBase: an open-source, single-file Go backend consisting of embedded SQLite, user management, real-time subscriptions, and an intuitive admin dashboard.
While many developers dismiss SQLite-backed solutions as toys incapable of handling production-level traffic, the reality is quite different. With strategic system engineering, it is entirely possible to achieve enterprise-grade performance on minimal hardware. This guide provides a deep technical walkthrough on how to optimize PocketBase on a entry-level $2 Virtual Private Server (VPS) to surpass 30,000+ requests per second (RPS), proving that scalability does not always require a massive cloud budget.
---Understanding the Constraints of a $2 VPS
Before diving into optimization techniques, it is essential to analyze the environment we are working with. A typical $2 monthly VPS from providers like Racknerd, Ionos, or similar budget hosts generally offers:
- 1 vCPU (often shared or fair-share allocation)
- 512MB to 1GB of RAM
- 10GB to 20GB of SSD storage
- Limited network bandwidth (typically 1 Gbps port shared)
Given these strict hardware boundaries, traditional heavy stacks like Node.js paired with microservices or Java running on a heavyweight framework would quickly trigger the Linux Out-Of-Memory (OOM) killer under heavy load. PocketBase, compiled into a single highly efficient Go binary, gives us a massive head start due to its exceptionally low idle footprint (under 30MB of RAM). However, to reach 30,000+ RPS, every layer of the operating system and database engine must be meticulously tuned.
---1. Operating System Tuning (Linux Kernel)
By default, standard Linux distributions (like Ubuntu Server or Debian) are configured with conservative network and file system limits designed for general-purpose compatibility, not high-throughput API serving. Under a massive load of 30,000 requests per second, the kernel will quickly drop connections or exhaust resources unless we adjust these limits.
Increasing File Descriptor Limits
In Linux, every incoming HTTP connection, open database file, and network socket is treated as a file descriptor. The default system limit is often set to 1024, which will cause immediate failure under load. We must raise these ceilings globally and per session.
Modify the system-wide limits by editing /etc/security/limits.conf and adding the following configurations:
* soft nofile 65535
* hard nofile 65535
Additionally, ensure the system-wide maximum is increased by adding this line to /etc/sysctl.conf:
fs.file-max = 2097152
Optimizing the TCP/IP Network Stack
When handling high-frequency HTTP requests, network sockets quickly cycle through states like TIME_WAIT. If the kernel does not recycle these sockets fast enough, the network stack will choke. Add the following kernel optimizations to /etc/sysctl.conf to safely handle rapid network recycling and large connection backlogs:
# Enable fast recycling of TIME_WAIT sockets
net.ipv4.tcp_tw_reuse = 1
# Increase the maximum number of open handles
net.core.somaxconn = 65535
# Maximize network packet queues
net.core.netdev_max_backlog = 50000
# Adjust TCP buffer sizes for higher throughput
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
Apply these changes instantly using the command: sudo sysctl -p.
2. Advanced SQLite Tuning for Concurrency
PocketBase leverages SQLite as its underlying data storage engine. While historically perceived as a single-user database, modern SQLite is an absolute beast when configured correctly for concurrent read-intensive workloads.
Enabling WAL (Write-Ahead Log) Mode
PocketBase enables WAL mode by default, which is critical for scaling. Unlike traditional rollback journal modes that lock the entire database file during a write operation, WAL mode allows concurrent readers to access the database while a write operation is actively occurring. This unblocks the API from bottlenecks caused by standard database locks.
Fine-Tuning Pragma Settings via Go Hooks
To push performance beyond the default configurations, we can tap into PocketBase's Go APIs to execute custom SQLite PRAGMA statements during database initialization. Creating a custom Go build allows us to inject these game-changing parameters:
- PRAGMA journal_size_limit = 67108864; – Prevents the WAL file from growing indefinitely, keeping it tightly cached in memory.
- PRAGMA synchronous = NORMAL; – Instructs the database to sync to the disk at critical checkpoints rather than every single write operation. This massively reduces disk I/O bottlenecks without sacrificing overall database integrity.
- PRAGMA cache_size = -20000; – Allocates roughly 20MB of RAM specifically for database caching, ensuring hot data structures remain instantly accessible in-memory.
By structuring these low-level modifications via native Go compilation, database latency drops to sub-millisecond levels under heavy read stress.
---3. Architectural Strategies: Caching and Indexing
System-level optimizations are highly effective, but poorly structured application logic can still degrade performance. To maintain 30,000+ RPS, you must implement strict data retrieval strategies.
Ruthless Database Indexing
Every single API endpoint that filters, sorts, or searches data must be backed by a precise database index. If a request forces SQLite to perform a full table scan over thousands of rows on a shared vCPU, performance will degrade instantly. Ensure that fields frequently utilized in queries—such as slug, status, or user_id—are explicitly indexed via the PocketBase Admin UI or a migration file.
Leveraging In-Memory Application Caching
The fastest database query is the one that never has to execute. Because PocketBase runs as a compiled Go process, you can build custom Go hooks or utilize JavaScript (ECMAScript) hooks to implement local in-memory caching for highly requested, static data (such as settings, homepage content, or public profiles).
By caching JSON payloads directly in the application's RAM using standard Go map architectures or tools like `go-cache`, requests can bypass the SQLite layer entirely, fulfilling requests instantly at the memory bus speed.
---4. The Edge Layer: Eliminating Heavy Reverse Proxies
In standard web server architectures, developers frequently place Nginx or Apache in front of their applications to manage TLS encryption and static assets. However, on a heavily resource-constrained $2 VPS, running an external reverse proxy introduces unnecessary process context-switching, consuming vital CPU cycles and RAM.
PocketBase features a highly optimized, built-in HTTPS server driven by Go's native net/http stack and automated Let's Encrypt TLS management via autocert. To maximize throughput, run PocketBase directly on ports 80 and 443 without an intermediary proxy layer. This direct-to-binary approach eliminates overhead, ensuring that every available clock cycle of your single-core VPS goes directly toward processing API payloads.
---Conclusion and Benchmarking Results
By implementing these specific system and database tuning adjustments, the performance metrics of a single-file backend change drastically. In controlled benchmarking scenarios using load-testing utilities such as k6 or wrk executing read-heavy API requests, a tuned PocketBase instance running on a single-core, 1GB RAM budget VPS comfortably clears the 30,000 RPS milestone, maintaining stable low-millisecond latencies.
This experiment demonstrates a powerful lesson for technical architects and business leaders alike: scaling isn't always about spending more money on infrastructure; it is about maximizing the efficiency of what you already have. By choosing efficient software foundations like PocketBase and aligning them properly with low-level operating system configurations, you can build blazing-fast architectures capable of serving immense production traffic for the price of a cup of coffee.