FAQ

This section answers common questions about fastapi-async-storages, explaining its purpose, differences from similar libraries, usage considerations, and extensibility options.

What is fastapi-async-storages?

fastapi-async-storages is the asynchronous counterpart to fastapi-storages. It provides non-blocking storage backends for FastAPI applications using async libraries such as aioboto3 for S3.

How is it different from fastapi-storages?

While fastapi-storages is sync-based and built around traditional blocking I/O, fastapi-async-storages is fully asynchronous. This allows your FastAPI app to handle more concurrent requests efficiently, especially during file upload or download operations.

Why upload files before commit?

SQLAlchemy’s ORM is primarily synchronous, even when used with AsyncSession. The model layer and column bindings (including file fields) are not async-aware. Therefore, storage operations like uploading or deleting files must happen before the database commit.

Does SQLModel integration work the same way?

Yes. The SQLModel integration layer internally uses SQLAlchemy’s async engine and sessions. You can define FileType columns exactly as you would in SQLAlchemy models, following the same upload-before-commit pattern.

Can I use it in synchronous contexts?

You can, but it’s not recommended. The library is designed around asyncio to take advantage of FastAPI’s asynchronous execution. If your app runs entirely synchronously, stick with fastapi-storages for simplicity.

Can I extend it with other storage backends?

Yes. The library’s base BaseStorage class is extensible. You can implement new async backends (like local filesystem, Google Cloud Storage, or Azure Blob) by subclassing it and implementing the async methods upload, get_path, and delete.

fastapi-async-storages aims to stay compatible with existing fastapi-storages APIs, so extension patterns remain familiar.