> Motivation for combining Chorus and SlateDB for NFS
I work on an AI agent (tasklet) and we give every agent a linux machine. Having durable storage that is cheap, fast and multi-tenant is really important for our product. NFS is a great protocol (if complicated), and object storage is just the cheapest. But making it fast and reliable is key.
> other use cases
Any use case for SlateDB that you are willing to pay more for less latency but keep disaggregated storage without another system.
> GCP specific
Actually AWS and Azure zonal storage also support append operations, so I think the approach could be extended to all three major clouds. I don’t have a need for that ATM
> pricing
Probably worth a whole separate blog TBH. It would be cheaper than Kafka but more expensive than just using the built in WAL for SlateDB or OSWALD
> Motivation for combining Chorus and SlateDB for NFS
I work on an AI agent (tasklet) and we give every agent a linux machine. Having durable storage that is cheap, fast and multi-tenant is really important for our product. NFS is a great protocol (if complicated), and object storage is just the cheapest. But making it fast and reliable is key.
> other use cases
Any use case for SlateDB that you are willing to pay more for less latency but keep disaggregated storage without another system.
> GCP specific
Actually AWS and Azure zonal storage also support append operations, so I think the approach could be extended to all three major clouds. I don’t have a need for that ATM
> pricing
Probably worth a whole separate blog TBH. It would be cheaper than Kafka but more expensive than just using the built in WAL for SlateDB or OSWALD