We're currently using half of our 3 GB volume (1,514 MB) with 26 registered users. If we have even hundreds of users, which would almost qualify as a modest success, we would clearly blow through the volume size very quickly.
We can delay the problem a bit by upsizing the volume, though the hard limit is 500 GB. This would support about 8000 users at our current utilization, though it is likely that if the app got popular and more people were using it all the way through, they would upload more data and this value could be much smaller.
We definitely can think about a data retention period, which would presumably help.
In reality, we probably just need to support additional volumes somehow. This is a complex architectural problem, since we also would presumably like to scale the application servers at some point, but a volume can only be attached to a single machine, and the sqlite3 database is currently sitting on a single volume attached to a single machine.
We're currently using half of our 3 GB volume (1,514 MB) with 26 registered users. If we have even hundreds of users, which would almost qualify as a modest success, we would clearly blow through the volume size very quickly.
We can delay the problem a bit by upsizing the volume, though the hard limit is 500 GB. This would support about 8000 users at our current utilization, though it is likely that if the app got popular and more people were using it all the way through, they would upload more data and this value could be much smaller.
We definitely can think about a data retention period, which would presumably help.
In reality, we probably just need to support additional volumes somehow. This is a complex architectural problem, since we also would presumably like to scale the application servers at some point, but a volume can only be attached to a single machine, and the sqlite3 database is currently sitting on a single volume attached to a single machine.