Use Cases & FAQs
Understanding how LoonFS compares to Git, S3, and to cloud drives like Dropbox and Google Drive.
Common use cases
Section titled “Common use cases”Embedded filesystem for platforms
Section titled “Embedded filesystem for platforms”LoonFS is fast, scalable, and easy to operate. This makes it a great fit for platform teams that need to embed a durable filesystem for multi-tenant and multi-user applications.
Standout LoonFS features that resonate with platform teams:
- every namespace is globally consistent, so concurrent users (humans and agents) observe a single commit order
- data transfer is high throughput and supports thousands of operations per second, and direct uploads and downloads can keep large payloads off the LoonFS server
- every namespace includes a serialized changefeed for simple and reliable derivative indexes and processing
Collaborative workspace for internal projects
Section titled “Collaborative workspace for internal projects”LoonFS is designed for operational simplicity and is great for projects that need a shared workspace without introducing a separate durable database or queue.
Strengths of LoonFS in this use case:
- LoonFS can be run as an embedded engine or self-hosted; in both cases, object storage is the only durable dependency
- LoonFS implements familiar filesystem commands and supports explicit transactions, revisions, and recovery
- the platform is built for composability and extensibility, making it an elegant fit for an evolving platform
Sync engine for desktop applications
Section titled “Sync engine for desktop applications”LoonFS state is derived from a globally consistent, durable write-ahead log with checkpointing and a changefeed. Most modern operating systems support native bi-directional file syncing capabilities on top of these primitives (including MacOS, iOS, and Windows), making it a perfect substrate for native filesystem syncing features.
How is LoonFS different from Git?
Section titled “How is LoonFS different from Git?”Git is version control for code-first projects. LoonFS is a transactional and versioned filesystem for platforms.
Git is a better choice when a client is expected to treat the entire filesystem as a single atomic project. LoonFS is a better choice for applications that need to upload, organize, search, update, and restore files in a shared workspace.
How is LoonFS different from S3?
Section titled “How is LoonFS different from S3?”LoonFS is a filesystem layer over S3, creating an indexed, transactional, and versioned filesystem from object-storage primitives. S3 supports atomic objects, while LoonFS provides transactional filesystem commits.
S3 is a better choice if your data model treats objects as values with keys. LoonFS is a better choice if your use case has files with paths, folders, stable IDs, revisions, transactional updates, and a consistent filesystem history.
How is LoonFS different from Dropbox, Box, or Google Drive?
Section titled “How is LoonFS different from Dropbox, Box, or Google Drive?”At the feature level, LoonFS has a lot in common with Dropbox, Box, or Google Drive. The key difference is around the deployment model and licensing: LoonFS is open source and built for embedding.
Though an apples-to-apples comparison is difficult, LoonFS should be faster than all popular cloud filesystems across most performance metrics.
Can I bring my own object storage bucket?
Section titled “Can I bring my own object storage bucket?”Yes. Though LoonFS provides the object storage bucket by default, you may configure your own bucket from any supported provider.
What object stores does LoonFS work with?
Section titled “What object stores does LoonFS work with?”LoonFS works with most S3-compatible stores, including AWS S3, Google Cloud Storage, Azure blob storage, and Cloudflare R2.
Is LoonFS transactional?
Section titled “Is LoonFS transactional?”Yes. A commit with many changes is applied as one transaction: it either lands completely or fails safely. Every read resolves against an isolated revision.
Is LoonFS POSIX-compliant?
Section titled “Is LoonFS POSIX-compliant?”No, and by design. LoonFS supports familiar filesystem operations — create, move, copy, delete, list, stat, and more — but trades POSIX compliance for exceptional performance and scalability as a cloud filesystem.
What are the latency tradeoffs?
Section titled “What are the latency tradeoffs?”Object-storage native architecture means that cold, uncached reads incur a worst-case of roughly 200ms of latency, and that writes in a busy namespace might take up to a second before durable acknowledgement (based on the cloud provider). We accept those tradeoffs in exchange for the scalability and efficiency of object storage.
What happens when files are deleted?
Section titled “What happens when files are deleted?”Deleting a file or directory moves it to the trash, where it can be enumerated and restored on demand. Separately, old revisions of existing files can be restored using revision history.
How big can a namespace get?
Section titled “How big can a namespace get?”LoonFS does not impose a fixed ceiling on the number of files in a namespace. Filesystem metadata is efficiently indexed so read and write operations stay fast even as a namespace grows to millions of files and revisions.
What is a namespace fork?
Section titled “What is a namespace fork?”A fork creates a new namespace from an existing one using a copy-on-write strategy. As a result, fork creation is very fast (under 1 second) and cost efficient.