It can work if all you will ever need is a key value store, but as soon as you need SQL-like queries (joins, filtering, transactions) you will be stuck reimplementing a sql engine in your app code.
I recommend to try SQLite with some kind of replication (either Linode disk snapshots, Litestream etc).
Having your state observable and local to your application instead of a slow http hop away makes development much easier.
- S3 Select: https://docs.aws.amazon.com/AmazonS3/latest/API/API_SelectOb...
- Athena: https://towardsdatascience.com/query-data-from-s3-files-usin...
How much is too much data? It depends. On things you won't be told. Varies day to day. Totally random.
Only if you're intent on keeping the s3-only architecture when it no longer makes sense, and the transition to SQL need need not be hard if you've been disciplined about your data structures from the get go.
I've been part of a transition from s3 only to s3/sql when business requirements changed, it only took us a week to set up a db, set up a workflow manager to insert necessary data into the db when something uploaded to s3, and ran some batch jobs for data that already existed. Total data in s3 was ~1pb.
IMO it's all about whether your problem space fits well with s3-only, and sometimes it does!