Turso
What is HardGraph? HardGraph publishes curated, provenance-backed agent skills grounded in reproducible vendor documentation.
Turso is a hosted platform; libSQL is the engine it runs. Treat them as separate layers: libSQL forked SQLite to add a server mode, an HTTP protocol, and native vector types, and its internals have since diverged further — "libSQL-compatible" is not "SQLite-compatible." Code depending on a specific extension, pragma, or concurrency quirk can behave differently. Don't assume parity; check the specific feature.
The distinction that causes production bugs
Turso ships two ways to keep data close to the app, with different consistency shapes:
- Embedded replicas are a local SQLite file mirroring a remote primary. Reads are local and fast; writes proxy to the primary. Replication back to the local file is not synchronous with your own writes — a write your process just issued is not guaranteed visible on the next local read unless you explicitly sync first. Write-then-immediately-read-back is the most common way this bites.
- Turso Sync is a newer, CDC-based alternative for local-first apps:
writes happen locally first, and you explicitly
push()/pull()to reconcile with the cloud primary — explicit, lower-bandwidth control instead of the embedded-replica model's read-through simplicity.
Picking between these two, or a plain remote connection with no local copy, is a data-model decision, not a client config flag — expensive to change once an app has shipped with one consistency assumption baked in.
Database-per-tenant is Turso's other headline pattern: many small, cheaply isolated databases (one per customer or user) instead of a shared schema with tenant columns. It changes migrations, connection pooling, and cross-tenant queries — there is no cheap join across separate databases.
Vector search (F32_BLOB columns and vector functions) lives inside the same engine as relational data, not a bolted-on service — schema and indexing choices differ from pairing SQLite with an external vector store.
What to verify rather than recall
- Whether embedded replicas or Turso Sync is currently recommended for a given workload — this has shifted as Sync matured.
- Exact sync/pull APIs and consistency guarantees per SDK language.
- Vector function names, index types, and dimension limits.
- Plan-level limits on database count, replica count, and storage per tenant at database-per-tenant scale.
- Pragma/extension parity when porting SQLite code, and what changes when self-hosting the libSQL server instead of using Turso Cloud.