Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3

I built a SQLite VFS in Rust that serves cold queries directly from S3 with sub-second performance, and often much faster.It’s called turbolite. It is experimental, buggy, and may corrupt data. I would not trust it with anything important yet.I wanted to explore whether object storage has gotten fast enough to support embedded databases over cloud storage. Filesystems reward tiny random reads and in-place mutation. S3 rewards fewer requests, bigger transfers, immutable objects, and aggressively parallel operations where bandwidth is often the real constraint. This was explicitly inspired by turbopuffer’s ground-up S3-native design. https://turbopuffer.com/blog/turbopufferThe use case I had in mind is lots of mostly-cold SQLite databases (database-per-tenant, database-per-session, or database-per-user architectures) where keeping a separate attached volume for inactive database feels wasteful. turbolite assumes a single write source and is aimed much more at “many databases with bursty cold reads” than “one hot database.”Instead of doing naive page-at-a-time reads from a raw SQLite file, turbolite introspects SQLite B-trees, stores related pages together in compressed page groups, and keeps a manifest that is the source of truth for where every page lives. Cache misses use seekable zstd frames and S3 range GETs for search queries, so fetching one needed page does not require downloading an entire object.At query time, turbolite can also pass storage operations from the query plan down to the VFS to frontrun downloads for indexes and large scans in the order they will be accessed.You can tune how aggressively turbolite prefetches. For point queries and small joins, it can stay conservative and avoid prefetching whole tables. For scans, it can get much more aggressive.It also groups pages by page type in S3. Interior B-tree pages are bundled separately and loaded eagerly. Index pages prefetch aggressively. Data pages are stored by table. The goal is

Hacker NewsToolAISource
0Sign in to voteCopy link

FL score

76

out of 100

Verdict

BUILD

low confidence

Competition

No competitor data yet

Trend

No signal yet

A SQLite VFS for S3 promises sub-second cold queries for multi-tenant architectures, significantly reducing costs and improving performance, but requires extensive validation and stabilization.

The pain

Architects building multi-tenant or per-user applications with SQLite struggle with the cost and performance overhead of persistent block storage for many inactive databases. These 'cold' databases incur significant expenses while offering slow access when needed.

The gap

There's a specific gap for a performant, cost-effective solution that allows SQLite databases to live directly on S3, offering sub-250ms cold JOIN query performance. Existing solutions either don't support SQLite directly on S3 or aren't optimized for this specific cold data use case.

Build angle

Develop a highly optimized SQLite VFS (Turbolite) that leverages S3-native features (range GETs, immutable objects, parallel operations, zstd frames) and SQLite B-tree introspection to enable fast cold queries for multi-tenant/per-user SQLite databases, reducing block storage costs.

Strengths

  • Addresses a specific, high-value architectural pain point (cost and performance of cold SQLite data at scale).
  • Technically innovative approach (S3-native VFS, B-tree introspection, prefetching) creates a strong differentiator.
  • Clear, measurable value proposition: cost savings and improved query performance.
  • Strong technical expertise demonstrated by the builder.
  • Growing market for serverless/edge computing and multi-tenant architectures where this solution fits.

Risks

  • The current state is 'experimental, buggy, and may corrupt data,' which is a critical showstopper for adoption.
  • High complexity for a solo builder to stabilize, make production-ready, and ensure data integrity.
  • Monetization and go-to-market are challenging until reliability is unequivocally proven.
  • The niche, while specific, might be smaller than initial perceived market size, requiring precise targeting.
  • Lack of current user validation or observations due to the project's early stage.

Next steps

  1. Prioritize stabilization and robustness: eliminate data corruption risks and ensure production-grade reliability.
  2. Develop a comprehensive test suite covering edge cases, concurrent access, and various query patterns.
  3. Create benchmarks demonstrating consistent sub-250ms cold query performance under realistic loads.
  4. Seek feedback from potential target users (architects, senior developers) on the stability and performance requirements.
  5. Focus on a minimal viable 'reliable' product that solves just the core pain point before adding more features.

Questions about this idea?

FlyBot reads the scoring and gives you a second opinion on “Turbolite – a SQLite VFS serving sub-250ms cold JOIN queries from S3”.

Open FlyBot