3 ms·

> Number of write (POST, PUT, PATCH, DELETE) requests is limited to 2k per month Many production applications use substantially more than this in 1 second. I t

> Number of write (POST, PUT, PATCH, DELETE) requests is limited to 2k per month Many production applications use substantially more than this in 1 second. I think even most people developing a project will exceed that limitation before even releasing it. You should put a disclaimer somewhere more obvious. Second note is, without indexing options, what's to distinguish you from S3, or Dynamo, or DocumentDB, or Mongo, or Rocks, Level, Foundation, Redis, Fauna, Postgres. JSON isn't enough, what's the hook?

moneywoes 3y ago
thanks, did not see this but it saved me time
mk0y 3y ago
Hey! Thank you for the feedback. Yes, it's very limiting (for now) since it's a free to use product right now. Indexing is done internally because the data model is arbitrary. This is key difference when we speak just about persistence. You will be making an app about groceries, someone else about movies. Indexing will be based upon your entities and sub-entity types.
- ralusek 3y ago
  This is the case for every database, but they still tell me what indexing options I have available. With an RDBMS I know that I can use hash key indexes for fast lookups on an exact key. I can use B-Tree indexes for range or partial key lookups. For S3 I know that I can do exact lookups, or prefix scans, and that scans occur in ascending order, but cannot be done in descending order, etc. I know nothing of what lookup schemes are available to me in your application, and what kind of Big O profile to expect from each. It has nothing to do with whether it's a grocery app or a movie app.
  - mk0y 3y ago
    First of all nodb isn't meant for really large scale applications. I will have to do a research on how to it best and simplest way possible. The idea behind nodb is simplicity - you start inserting data in no time. Indexing of what you talk about is currently not possible. I will definitely look into it though and restructure it if necessary. Thanks for elaborating and the feedback, much appreciated. I will post again when I have updates.

moneywoes 3y ago

thanks, did not see this but it saved me time

mk0y 3y ago

Hey! Thank you for the feedback. Yes, it's very limiting (for now) since it's a free to use product right now. Indexing is done internally because the data model is arbitrary. This is key difference when we speak just about persistence. You will be making an app about groceries, someone else about movies. Indexing will be based upon your entities and sub-entity types.

ralusek 3y ago
This is the case for every database, but they still tell me what indexing options I have available. With an RDBMS I know that I can use hash key indexes for fast lookups on an exact key. I can use B-Tree indexes for range or partial key lookups. For S3 I know that I can do exact lookups, or prefix scans, and that scans occur in ascending order, but cannot be done in descending order, etc. I know nothing of what lookup schemes are available to me in your application, and what kind of Big O profile to expect from each. It has nothing to do with whether it's a grocery app or a movie app.
- mk0y 3y ago
  First of all nodb isn't meant for really large scale applications. I will have to do a research on how to it best and simplest way possible. The idea behind nodb is simplicity - you start inserting data in no time. Indexing of what you talk about is currently not possible. I will definitely look into it though and restructure it if necessary. Thanks for elaborating and the feedback, much appreciated. I will post again when I have updates.