[sowbug]

I believe your question is equivalent to the question of solving the tragedy of the commons, which suggests it's indeed a tricky problem.

As a strawman proposal, we could take some of Elinor Ostrom's suggestions for a non-governmental solution (https://en.wikipedia.org/wiki/Tragedy_of_the_commons#Non-gov...) and apply them:

1. Introduce the concept of an API key to allow users to voluntarily segregate the traffic into accounts. API keys are only voluntary because it's easy to extract someone else's key from a client binary and masquerade as that person.

2. Issue API keys only to users who agree to a set of community standards.

3. Nontrivial usage that still complies with the community standards requires payment. The payment should be structured so that it's reasonable for medium-traffic users to stay, but more economical for heavy-traffic users to leave the community and start up their own clone of the service. For style points, the community standards should have specified that anyone who starts with the free community service and graduates to hosting a clone must also host low-traffic free users, basically causing the service to become federated. Maybe the original service replies with 301 redirects to the new service so that old clients keep working.

I think all of this can be fully automated, and if you're cool accepting Bitcoin for usage above the free tier, then you don't even have to worry about how to handle payments. There are plenty of VPS providers that accept Bitcoin these days, so the system is even closed-loop from the perspective of the service operator.

[jsondata]

I built essentially what you describe a while back (jsondata.io if you're interested, though the certificate has expired and I've turned off the actual service for now). The idea was to make an infinitely scalable (within reason) solution that works well as a pastebin-style, no-setup-required data store for hacking on projects, but also as something that can scale with the needs of a business.

The architecture is built on AWS Lambda and DynamoDB, along with a small Ruby Sinatra service to handle payments and access control.

After running it for a while and getting some limited feedback from potential users/customers, I ultimately abandoned the project due to an apparent lack of interest. For hobby projects, it's fairly easy to spin up a self-hosted data store for low volume needs (or use one of the other free services). For anything more than that, a business is probably going to spend the necessary time/money to maintain a full DBMS or use something like Firebase.

I might be missing an opportunity (I've had thoughts about resurrecting the project), but for the time being, I'm just not convinced there is enough demand on the paying side.

[sowbug]

Part of the fun of prototyping is setting up your own service; at least, I always find that part fun. That likely eliminates some of the target market.

If the service API were fully standardized, and users paid for their own database, and signing up for a new website meant that the user granted controlled DB access to the site, then that might be enough impetus for developers to use a provider of the service. Maybe it could follow a Dropbox model where the first N bytes/month are free per user, and service providers pay affiliate fees to sites that recruit lots of paying users.

See also Attic Labs (https://techcrunch.com/2018/01/08/salesforce-acquires-attic-...).