---
title: "Skip the API, Ship Your Database"
description: "The post describes an unexpected use for LiteFS, a distributed SQLite database: replacing service-to-service APIs with read-only database replicas. Typical APIs require anticipating access patterns; shipping the full database lets clients use SQL joins, aggregation, and windowing locally, while one-way LiteFS replication avoids chatty gossip and is simple to configure with an upstream primary hostname. Moving queries to client hardware removes shared service compute contention and the need for tenant rate limiting and timeouts, but replicas cannot handle mutations and raw schema changes create looser contracts, mitigated by backward-compatible changes and views. Data access is harder to restrict in multi-tenant databases, so per-tenant SQLite files are a suggested workaround. The approach is positioned for specific read-heavy use cases, potentially including local copies of Stripe or GitHub data, with event buses such as Kafka generating per-tenant databases."
---

# Skip the API, Ship Your Database

[Fly.io](https://yomu.fyi/company/fly-io) · Sep 13, 2023

**Type:** Explainer

## Summary

The post describes an unexpected use for LiteFS, a distributed SQLite database: replacing service-to-service APIs with read-only database replicas. Typical APIs require anticipating access patterns; shipping the full database lets clients use SQL joins, aggregation, and windowing locally, while one-way LiteFS replication avoids chatty gossip and is simple to configure with an upstream primary hostname. Moving queries to client hardware removes shared service compute contention and the need for tenant rate limiting and timeouts, but replicas cannot handle mutations and raw schema changes create looser contracts, mitigated by backward-compatible changes and views. Data access is harder to restrict in multi-tenant databases, so per-tenant SQLite files are a suggested workaround. The approach is positioned for specific read-heavy use cases, potentially including local copies of Stripe or GitHub data, with event buses such as Kafka generating per-tenant databases.

## Context

LiteFS was initially intended to distribute data geographically, and its Corrosion test deployment exposed a way to make server state available to internal services without designing an API.

## Approach / What changed

Run read-only LiteFS instances downstream from an upstream primary node, streaming a full SQLite database to client services so they can query it locally with SQL. Per-tenant databases can limit data exposure in multi-tenant environments.

## Takeaways

- Clients can query and join a full local database with vanilla SQL, including aggregation and windowing that the post says GraphQL does not provide as built-in capabilities.
- Read-only replicas move query computation onto each tenant’s hardware, reducing concerns about shared resource contention, rate limiting, and query timeouts.
- Replicas do not support mutations, and shipping raw schemas makes contract changes harder; backward-compatible schema changes and database views can help preserve compatibility.

**Tags:** [Distributed Systems](https://yomu.fyi/topic/distributed-systems), [LiteFS](https://yomu.fyi/topic/litefs), [SQL](https://yomu.fyi/topic/sql), [SQLite](https://yomu.fyi/topic/sqlite)

- Source: [Fly.io](https://fly.io/blog/skip-the-api)
- Source URL: https://fly.io/blog/skip-the-api
- Ingested by Yomu: 2026-09-02T11:59:20.893Z

[Read original post](https://fly.io/blog/skip-the-api)