How Sample Vault syncs gigabyte-scale databases from cloud to local with Turso

Sample Vault is an AI-powered sample browser for music producers built by Wojciech Adamek, CEO of Feathered. It indexes libraries of 100,000+ audio files, extracts spectral and ML-derived metadata, and enables natural language search so producers can find sounds by description rather than filename. Files are never moved or renamed. A free tier runs local-only; the premium tier adds cloud sync across devices.

Most local-first applications sync in one direction: data is created on the client and pushed to the cloud. Sample Vault needed the reverse. Processing happens in the cloud. The results sync down. Users query offline against a full local replica of their indexed library.

Sample Vault runs on Turso for cloud-to-local bidirectional sync with per-user databases.

Workload	Per-user databases containing 100K to 1.2M+ indexed audio files
Architecture	One Turso database per premium user, cloud-to-local embedded sync
Outcome	Gigabyte-scale offline-first access, zero custom sync code

#The problem

Professional producers don't have small libraries. They typically manage over 100,000 samples, and the largest Sample Vault user today has over 1,200,000 indexed files.

Sample Vault's processing pipeline runs each file through audio analysis, ML classification, and AI tagging. That generates a lot of metadata per file: 40+ spectral features, classification labels, genre and mood tags, virtual directory mappings. For a million-sample library, the resulting database is measured in gigabytes.

Two constraints make the database decision hard.

Files cannot be moved or renamed. Producers build projects that reference samples by absolute path. "Any kind of file movement is very common for production projects to break," says Wojciech Adamek, Founder/CEO of Sample Vault.

The app must work without internet. "A lot of producers really like to work in offline environments. So they really need the data to be accessible locally and work without internet connection."

So the requirements add up to: gigabyte-scale per-user databases, full offline support, and a sync layer that pushes processed data from the cloud down to the client. Finding a database that could handle all of this turned out to be harder than the application logic itself.

#What didn't work

Wojciech tried three architectures before Turso.

Supabase put everything in the cloud with multi-tenant PostgreSQL. It required constant connectivity, uploads were slow at this scale, and vector similarity search was unreliable. "It made the application quite inaccessible because it always needed cloud connection, and it always needed people to upload the data to the cloud, which is also slow and didn't quite work well for libraries of these sizes."

PGLite moved PostgreSQL local via WebAssembly. RAM usage hit 1 GB+ for large libraries on machines already running memory-intensive DAWs. Cross-platform support was poor. And there was no sync layer at all, meaning the Sample Vault team would have to build one from scratch.

"As a software architect, I know very well these kinds of things are really hard to get right and to implement and maintain. So I really wanted to avoid that at all costs."

Electric SQL and PowerSync offered SQLite with cloud sync, but at enterprise pricing that didn't fit an independent project. More importantly, they sync local to cloud. Sample Vault needed the opposite direction.

#The architecture

Turso gave Sample Vault two capabilities no other option could: bidirectional sync that includes the cloud-to-local direction, and database-per-user multi-tenancy without operational overhead.

#Cloud-to-local sync

1. User scans local audio files
2. File metadata sent to Turso Cloud (per-user DB)
3. Cloud runs processing pipeline:
     - Deterministic audio analysis (40+ spectral features)
     - ML sound classification
     - AI tagging (genre, mood, instrument, creator)
4. Processed database syncs DOWN to user's machine
5. User queries offline against local replica
6. Local writes sync BACK to cloud

The cloud database is the source of truth. The local Turso embedded replica is a full copy of the user's database. Heavy processing runs asynchronously or server-side while users query their complete library offline, without waiting for computation to finish on their machine.

Sync runs on three triggers: app launch, every 5 minutes in the background, and on-demand when the user requests it. "The user can just start the app and sync later whenever he has connectivity."

#Database per user

Each premium subscriber gets a dedicated Turso database, provisioned automatically on subscription. Free users run fully local with no cloud dependency.

"Whenever a user subscribes to my application, I automatically provision the database for them, and whenever they open the application, they immediately connect with that database specifically."

This eliminates the noisy-neighbor problems from the original multi-tenant PostgreSQL setup. Each user's data is fully isolated at the database level, with no shared tables, no row-level filtering, and no cross-tenant performance interference.

#Data model

One row per audio file. Each row stores file path and basic metadata (name, size, duration), a virtual directory path that mirrors the user's folder structure without touching it, 40+ deterministic spectral features (key, tempo, brightness, complexity, stereo width), ML classification results, and AI-generated tags for natural language search.

Audio files never leave the user's machine. Only metadata and analysis results move between local and cloud.

#Results

Scale today:

• 1.2M samples indexed for the largest user
• 100K+ samples typical for professional users
• Gigabyte-scale per-user databases
• Full offline capability after initial sync
• Zero custom sync code to build or maintain

"Turso's sync was much, much better than LibSQL, especially for my use case with databases potentially reaching gigabytes in size. It seems to work seamlessly with any amount of data. Even for large databases, startup while we're pulling the data was something of a non-issue for my use case."

Scale ahead:

"Based on my market research, as my application grows, that could easily be the case where we could see over a million premium users and databases." Turso's database-per-user model accommodates that without additional infrastructure work.

#What shipped instead of sync infrastructure

The engineering time not spent building a custom sync layer went directly into the features that differentiate Sample Vault:

• Deterministic audio analysis extracting 40+ spectral features per file
• ML-based sound classification that automatically identifies what each sample contains
• AI tagging with "a touch of non-deterministic thought process that cannot really be emulated through any kind of audio analysis"
• Natural language search so producers can query by description ("warm wide pad with slow attack, not too bright") rather than filename

"It's mostly a matter of opportunity costs. I'm a software architect by trade, so I could roll my own. But I really wanted to avoid that at all costs." For an independent founder whose project started as a passion project and is "slowly turning into a real venture, a real startup," the database layer not being a time sink changed the trajectory of the product.

#The migration from libSQL to Turso

Sample Vault started on libSQL directly before switching to Turso with support from the team.

"At first, I started with LibSQL, but it had some sync limitations that blocked me from using it. But then on the Discord, I was talking to Preston, and he recommended I just switch to Turso, and the guys from the team helped me switch completely to the actual Turso database."

Wojciech was candid about running on beta software: "I did find quite a few quirks and quite a few issues with performance in regards to some specific features I was using. But the Turso team helped me find workarounds and fixed a bunch of things for me live as well. Given that the team is very helpful and very supportive, that's a small cost to pay for software this modern."

#When this pattern fits

Sample Vault's cloud-to-local architecture applies to workloads where processing is heavy and better suited to server-side or async execution, where clients need offline access to large processed datasets, and where multi-tenancy requires database-level isolation rather than shared tables.

For workloads with that profile, cloud-to-local sync removes the need to build custom replication, handle conflict resolution, or manage per-tenant infrastructure. The cloud database holds the processed result. Every client is a full local replica.

"For my use case, I really didn't find any other alternative." — Wojciech Adamek, Founder, Sample Vault