Dev

Popular Site lobste.rs Successfully Migrates to SQLite, Reducing CPU Usage and Halving Costs

Social news site lobste.rs has completed its migration from MariaDB to SQLite. CPU and memory usage have decreased, and VPS costs have been halved. The article details the migration process and the technical challenges, offering valuable lessons.

6 min read Reviewed & edited by the SINGULISM Editorial Team

Popular Site lobste.rs Successfully Migrates to SQLite, Reducing CPU Usage and Halving Costs
Photo by Growtika on Unsplash

The social bookmarking and news site “lobste.rs” has successfully migrated its database from MariaDB to SQLite. The transition went live in the production environment on July 11, 2026, and withstood the increased traffic on Monday, resulting in a significant decrease in CPU and memory usage, improved site responsiveness, and a halving of VPS costs. This migration project, which began in 2019, was realized after nearly seven years of trials and iterations.

Background and Timeline of the Migration

For many years, lobste.rs operated its database on MariaDB. However, in 2025, the acquisition of its developer MariaDB Corporation by K1 Investment Management sparked serious discussions about database migration. These discussions were publicly documented in the Lobsters issue “#539 Migrate to SQLite.”

According to a report by Lobsters user thomas0, he initially discovered this issue in 2019 and suggested migrating to MySQL due to its compatibility. However, in 2025, amidst discussions around migrating to PostgreSQL, a detailed analysis by a user named Rahul on whether “lobste.rs could run on SQLite” brought SQLite into the spotlight as a viable option.

thomas0 officially joined the project in June 2025. Although the migration was discussed during Lobsters’ office hours, concrete work did not begin until August of the same year. The first pull request was eventually closed due to time constraints, but the second pull request focused on performance testing and the creation of database migration scripts.

Lessons Learned from Two Initial Failures

The migration didn’t proceed without setbacks. On February 21, 2026, the first production deployment was attempted. Developers @pushcx and thomas0 meticulously prepared a checklist to ensure everything was ready. Despite their efforts, issues arose in the production environment. Although the site operated in read-only mode, the read traffic consumed 100% of the CPU.

The issue stemmed from the lack of access to the production database, which prevented pre-deployment performance testing. The developers quickly decided to roll back. thomas0 later reflected on the initial failure, admitting it was a disheartening experience.

Two days later, on the third attempt, the final pull request was submitted with three key fixes:

  1. Optimization of two queries that caused full table scans on the largest table.
  2. Resolution of the N+1 query problem.
  3. Fixes to minor issues discovered in the search functionality during the initial deployment.

To validate performance, a bulk data generation script was developed to create a local dataset at half the scale of the lobste.rs database. This script took approximately a week to execute.

Actual Benefits and Operational Results

The migration yielded several benefits. First, CPU usage dropped significantly. Memory consumption also decreased, leading to improved site responsiveness. The most noticeable change was in cost reduction; shutting down VPS instances dedicated to MariaDB led to a 50% decrease in server expenses.

“We’re having a calm Monday,” remarked thomas0, reflecting on the post-traffic peak period. Since the migration, no issues such as system failures or performance degradation have been reported.

The issue “#539 Migrate to SQLite” was officially closed on the morning of July 13, 2026. This project stands as a case study in community-driven database migration, taking over seven years to complete.

Notable Technical Highlights

One of the most remarkable aspects of this migration is that lobste.rs chose SQLite as the backend database for their web application. Traditionally, SQLite is considered suitable for embedded use or small-scale applications, while relational database management systems (RDBMS) like MariaDB or PostgreSQL are preferred for web services involving concurrent writes.

However, the case of lobste.rs demonstrates that SQLite can be sufficiently practical for sites with specific traffic patterns. By properly managing concurrent connections and serializing writes, complexity in middleware can be reduced.

The database conversion scripts and performance testing methods developed during this migration offer valuable insights for other projects considering similar transitions. thomas0 created a custom database conversion script from MariaDB/MySQL to SQLite, as existing tools did not meet the project’s needs.

Community Reactions and Future Prospects

The lobste.rs community has warmly welcomed the successful migration, with many users lauding the smooth transition. The phrase “a calm Monday” became a symbol of the project’s success.

Nevertheless, SQLite has limitations in areas like concurrent write performance and replication capabilities compared to RDBMS systems. While lobste.rs operates as a small-scale hobby project, similar migrations may not always work for larger services. Organizations should carefully assess their operational scale and traffic patterns before adopting SQLite.

The developers are open to answering questions about the migration, and more technical details and know-how may be shared in the future. The performance improvements achieved, such as the Linux Cache Aware Scheduling extension’s reported 360% speedup for MySQL, highlight the significant impact database choice and optimization can have on overall application performance.

The use of SQLite as a backend database for web applications could potentially expand to small- to medium-scale projects. For those looking to reduce MySQL or PostgreSQL operational costs, this case provides a clear example of the migration process and its challenges.

Editorial Opinion

In the short term, this successful migration could influence small- to medium-scale web service operators. SQLite requires less configuration and operational effort, eliminating the need for dedicated database servers or management tools like MariaDB or PostgreSQL. For sites with similar traffic scales, the potential to cut VPS costs in half may encourage broader adoption of SQLite. For individual developers and small teams, this broadens the range of database choices available.

From a long-term perspective, this case could prompt a reevaluation of SQLite as a “production database” for web applications. Historically dismissed as a “toy” database, this example from lobste.rs demonstrates that with appropriate workloads and query optimizations, SQLite is viable for real-world applications. However, it remains unsuitable for services with heavy concurrent writes or those requiring replication, highlighting the need for careful assessment before adoption.

As an editorial question, we suggest reflecting on the balance between “well-tested existing options” and “new options for cost optimization” in database migrations.

References

Frequently Asked Questions

What was the main reason for lobste.rs migrating to SQLite?
The acquisition of MariaDB Corporation prompted discussions about transitioning to a simpler, lower-cost database. SQLite offers ease of configuration and operation, eliminating the need for dedicated database servers, which led to reduced VPS costs. The migration resulted in decreased CPU and memory usage and halved server expenses.
Is SQLite practical as a production database for web applications?
With the right workload and query optimization, SQLite can be practical. In the case of lobste.rs, its traffic patterns with limited concurrent writes allowed SQLite's constraints to be managed effectively. However, for services requiring high concurrency or heavy writes, traditional RDBMS solutions like PostgreSQL or MySQL are more suitable.
What were the main technical challenges during the migration?
The main issue was performance-related. During the first deployment attempt, SQLite performed full table scans on the largest table, causing CPU usage to spike to 100%. This was resolved by optimizing three queries: adding indexes, addressing the N+1 problem, and fixing minor search functionality issues. Additionally, the lack of pre-deployment testing on the production database posed a significant challenge. ## References - [Lobsters: lobste.rs is now running on SQLite](https://lobste.rs/s/ko1ji1/lobste_rs_is_now_running_on_sqlite) — Published on July 13, 2026 - [Linux Cache Aware Scheduling Extension, Achieving up to 360% Speedup for MySQL](https://singulism.com/en/linux-cache-aware-scheduling-mysql)
Source: Lobsters

Comments

← Back to Home