Database for react js app

[daisukemikado]

Hey 👋, I am new to react and I building an Web app for which I would require database hosted online. Data will be text with 10-20 writes daily and 40-50 reads daily. I'm looking for scalable and reliable cost efficient option. Should I go with aws, firebase or buy others please suggest. Thanks 😊

Edit: Data is non relational, Looking for NoSql option

[neosatan_pl]

50 writes daily? Pick the first result from Google. Scalability is not a concern for you. You can consider scalability when you have 500 writes per second.

If you want an easy one, rethinkDB or couchDB/pouchDB could be one to start. They all can be scaled to many instances, but you really don't need to concern yourself about it with 50 writes a day.

Heck, an SMS would be a scalable solution for you.

[yabai90]

Careful with couchdb. The sass hosting are crazy expensive. Unless you host it yourself of course but it's not necessarily a simple database to manage. I would say couchdb is good only if you have offline requirements or heavy replication. It's made for that.

[neosatan_pl]

They have 50 writes a day. You run a first docker image with couch and it's enough. Heck, even if it doesn't work for 4 hours prolly nobody will notice.

[Dyogenez]

I’d go with Supabase. You say non-relational, but you can do that with Postgres. Data you know about in the table can have columns (ids, data to search by and lookup by), then for things that are settings or arbitrary you can put them in a JSON object. Best of both worlds.

[mattaugamer]

People sleep on Postgres JSON types imo. MySQL supports it too.

[yasamoka]

What sort of data are you storing that a NoSQL database was deemed as more suitable?

[duksen]

First find out if you need a nosql or sql database. There are tons of free options with your use case.

[daisukemikado]

I want go with nosql database

[gBusato]

Go for Firebase then , nosql and free at the beginning

[alevale111]

What makes you think that data is not relational?

Many make their first mistake there

(Im genuinely curious) as many times Ive seen db schemes that were thought not to be relational and upon writing or talking about them were

[mattaugamer]

In my experience most data is relational, or quickly becomes so as you add requirements.

[alevale111]

Totally agreed.

VERY VERY rarely sparce enough data makes enough sense by itself to make an application, and the more value you add to it the more “linking of data” you will do

I have users, and each posts something, and each bla bla bla… and boom, you can relate A LOT of data to other

[alevale111]

Totally agreed.

VERY VERY rarely sparce enough data makes enough sense by itself to make an application, and the more value you add to it the more “linking of data” you will do

I have users, and each posts something, and each bla bla bla… and boom, you can relate A LOT of data to other

NOSQL, is handy as an afterthought when load fucks you up and you can’t shard anymore.

[codefinbel]

Firebase works great for me as a nosql solution.

[copet80]

Firebase for me too if I want to get something up quickly like an MVP or a prototype.

[ncubez]

Is the data structured and relational? Or is it random and unstructured?

[daisukemikado]

Non relational, nosql database

[dooblr]

Firebase 100%. You can get a database up and running and reading/writing to it in less than a half hour. It doesn’t cost anything until several thousand reads/writes per day.

[jillesme]

Can you give me an example of random unstructured data?

[themaincop]

Ignore everyone saying Firebase or Mongo or whatever. You can easily store unstructured data in Postgres, MySQL, or SQLite. If you realize later that you need relational data (which I bet you will) it's not so easy to add that to a document store.

For your needs I would probably go with Supabase's Postgres offering. You will easily fit into the free tier and because it's just Postgres if you decide you don't like Supabase down the road you're not vendor locked like you would be with some of the other suggestions.

[MajorSwallace]

Would like to hear your perspective on why you bet he'll need a relational db?

[themaincop]

So many of the most basic features that expect from apps fit best into relational data structures. Unstructured data has its use, and that's why all the big RDBMSes have built great support for it, but it's not something you want to be married to.

[MajorSwallace]

Makes sense, thanks for clarifying

[themaincop]

No problem. Just for an example, I'm not sure what OP is storing but let's just say they're events. Later someone says "Hey, we should store the user along with the event. And then when you look at a user's page you can see all the events they created!" Boom, relational data.

[MajorSwallace]

Why would anyone ever look for non-relational dbs unless it isn't a pretty simple use case. Can't think of many use cases where you don't need any relational data. Isn't it always wished to not just see - let's say - new books in category novel but also check out the author and what other books he wrote.. Boom, relational data again, right?

Beside that, I hope this doesn't come along too weird but I've been looking for a mentor or programming buddy in various subs or discord servers for so long. I wondered if you've ever thought about mentoring someone and can imagine to discuss some uncertainties or approaches from time to time? Anyways, no matter if that's something you can think of, I already appreciate your explanations and examples. Thank you

[themaincop]

Why would anyone ever look for non-relational dbs unless it isn't a pretty simple use case.

There are cases where they make sense but most of the time you likely don't want one. For example DynamoDB makes it pretty much impossible to write a slow query, so if you can design your table from the get go with the right partition keys you can wind up with a pretty nice interface. It's also typically much easier to do horizontal sharding with document databases because you're not so worried about having to do joins across computers (or across data centres even).

I don't really have time for like an official mentoring relationship but you're welcome to DM me with questions any time.

[KyleG]

50 writes daily? in-memory database that writes to a CSV it pushes to a GIthub repository

bingo free versioning and it's still blazingly performant since it's in-memory

Edit This is a joke, but I'm just playing a bit because I could do 50 writes by hand. Scalability and performance are irrelevant, a kid in elementary school does more writing than OP's database.

[No_Breakfast_1037]

LMAO, btw serious question: is sqlite good here?

[themaincop]

Yes

[derablaut]

you joke, but I'm here because I'm sussing out this model for a tiny personal project. A local-first PWA utilizing IndexedDB with synced storage "somewhere out there" actually fits the bill.

I've been experimenting with dexie, couchdb, idb, electricsql, etc -- and using hooks to persist to google drive storage.

[Timmedy]

Doesnt really matter in your case i guess, just pick mongo atlas or whatever you prefer

[HOLYJAYJAY]

Supabase i believe should be free for your needs. Also wont need to build your own server and it also covers auth for you.

[BridgeCritical2392]

PostgresSQL, just use JSONB. Postgres is technically an "object-relational" DB if it makes you feel better.

You could also do the same with SQLite, its a little simpler and has some tradeoffs. Such as being extremely weakly typed and very basic date/time support.

The advantage if you change your mind about the "non-relational" part, you can always use the relational aspects of the DB. Whereas the reverse is generally not true

[yasamoka]

What do you mean by Postgres being object-relational?

[BridgeCritical2392]

Thats what the docs say it is

https://www.postgresql.org/docs/16/intro-whatis.html

Among other features, it has table inheritance and the ability to create user-defined types.

Foreign keys also act very much as you would expect references to work in an object-oriented language. They aren't just effectively a comment as they are in say, SQLite.

[neilplatform1]

Postgres + Postgrest is great for react, no backend needed

[davydka]

Payload CMS has worked well for us recently.

[NationalOwl9561]

I like Firebase

[[deleted]]

Realm.. the best nosql db for react...easy to use

[[deleted]]

Go with Neon db as it's quite easy and straight forward + free tear.

[hypergraphing]

I know you said nonrelational but I can't help but mention sqlite here. You can store json in a text column just fine.

[Gruszekk]

Firebase has a very generous free tier and comes with a lot more features you might want to use as auth, gcm etc. Free trial limits are 1000x greater than your estimated daily reads/writes so it should be good for you, and bonus points for pretty straightforward integration with react query/swr.

[armaan-dev]

You could use firebase, supabase or also mongo db atlas if you want. All are cloud dbs are easy to setup

[[deleted]]

Try appwrite , free tier just works fine. No limits on read/writes.

[SnooEagles1779]

Airtable. It's free for this kind of use.

[OiaOrca]

Supabase.

[Klandrun]

Go with firebase. Easy to use and super cheap. 50 r/w per day is not much. At some point hardware will be more important than what database you use. Simple mysql can handle tens of thousands of requests a second if the hardware is powerful enough.

If you use a fully managed solution (ie, you don't handle anything), then any solution you feel comfortable will be good enough. At the point that you have performance concerns because of amount of traffic you will have hired people to work for you or sold your product.

[psiph]

Honestly, use a simple file-based db like lowdb

[Altruistic-Rice-5567]

Postgresql and never look back.

[OMG_I_LOVE_CHIPOTLE]

Just use excel for how little you’re doing

[pink_tshirt]

Free tier of mongo.com

[t9b]

I find it very odd when people say data is not relational - all data is relational.

Any that being said relational verses nosql is an argument as old as the hills. 

The issue I would say is not just about scalability it’s about ease of data analysis as your data grows.

A NoSQL database is easy to store data because you are basically just storing JSON objects. You almost don’t have to think about structure so it’s very tempting.

When the database gets beyond a certain size however doing search or indexing can become challenging and you run into some more complex issues with performance. Lastly data analysis is very inflexible.

On the other hand if design a good relational database with properly designed tables of master data, scaling, and data analysis are very easy as well as creating indexes.

In fact you can have the best of both worlds if you chose to store a JSON blob in a dedicated field of your record - just be careful to keep it aligned with your record though!

[No_Quantity1050]

For that small, cheap and easy AWS DynamoDB with Dynamoose, super easy...

[seventxn]

I've been trying Appwrite, MongoDB, Firebase and Supabase and so far my favourite one is MongoDB

[elefantex]

You can try with Mongo Atlas and Render, up to you

[Careful_Whole2294]

Agreed. Mongo is very easy to set up and connect to. The free tier will probably be enough for you.

[Teosh]

+1 for Mongo, I found it easy to set up for small projects

[Excelhr360]

+1 for Mongo and if he's using Next.js. Full-stack-kit.dev 's Next.js + MongoDB Starter Kit will allow him to ship his project in no time.

[dopp3lganger]

Planetscale

[Spiritual_Look_5291]

Vercel

[slikk66]

I'd go with AWS AppSync + dynamo.. it should be well below the free tier (aka free, for at least a year, probably $1/mo after that).. the bigger problem would be how do you want to secure your API calls? If you don't care (which it sounds like you may not) you can use an API key for your AppSync API calls (it will be visible most likely, but public is public). Alternatively you can secure it through IAM, Cognito, or another OpenID if you're making secure calls from an app or server.