You sound like you might just be getting started so I'd suggest you stick to very well known patterns and not try to overcomplicate the DB design.
In other words: you should just have 1 SQL DB, multiple tables. Design the tables and columns appropriately using the right data types, and ask ChatGPT for help if you're not sure which data type to use.
Avoid:
- Multiple DBs, NoSQL, and any kind of premature optimization. Worry about 1 million users/visits problems when you get to that level, and even at that level modern RDBMS software can handle that kind of load on a single DB server.
- MongoDB and non-relational DBs. Mongo tends to lie about what their databases can handle despite fancy "transactions" marketing on their site
If you don't believe me, note the no less than 5 separate studies (!) into how Mongo loses writes and experiences other problems you really don't want to have to think about: jepsen.io/analyses
To be fair, these studies are slightly old and it's very possible they've been addressed by now, but Mongo has been guilty many times of misleading marketing practices. I wouldn't place my trust in this kind of entity.
Instead, use and learn:
- Very well known and tested databases where experts have verified their behavior properly so that you don't have to worry about unexpected surprises in production. PostgreSQL and MySQL are both good choices for this reason.
- SQLite is also OK to stick with, but you might have to think about extra things like restoring the DB from a backup if the server dies. I'd advise just using any "database as a service" provider like Amazon RDS and picking Postgres/MySQL as I mentioned - Amazon has a free tier, handle automated backups and persisting data for you so that you don't have to worry about it.
Hey @ben, Thanks for the detailed replied. Its very useful. I've made up my mind, and I want to stick with sqlite for now. Until, I've something good. I want easy things to get started and want to convert my ideas into reality.
I'm curious what kind of use case you have where jsonb won't work considering Postgres typically benchmarks well (ironically, better than Mongo) when dealing with jsonb data
And yeah I'm not saying it's not possible. You can be successful with any DB choice really and Marc's use cases work fine with Mongo (I don't know all of his apps, but most of the ones I've seen either don't have persistence requirements or have pretty simple data models that can basically be stored in anything including Mongo), but I typically don't recommend Mongo to new people because I've seen a lot of folks shoot themselves in the foot trying to force relational data into a document format just because they don't know any better
What I mean by that is that it's really easy to look at Mongo if you don't have a lot of experience and think "oh yeah, I can represent everything I could ever hope to store in a database using a JSON doc" even if there might be relationships between entities that are better off in a typical RDBMS and not a document DB. I mean, I've seen people do wild shit like attempt to represent an entire social graph for a user in a mongodb document. That's where the danger is in my view.
Why I had to go to Mongo: I really needed something that was "json first". I got 3000 different fields/keys, but my largest documents only have 100 fields at most. So a huge number of the fields only appear in a sub-set of the documents.
True Marc's use cases have simple requirements, but that is true for most newbies. In a way I'd say Mongo is better for newbies doing simple stuff than experienced engineers building complex apps...
Even works with two dashes, from what I can see. Maybe even one.
Yeah, seems to be there is a case of MD injection here, which if true, might be possible to lead to an MDX injection, at which point your cookies are mine ;-)
You sound like you might just be getting started so I'd suggest you stick to very well known patterns and not try to overcomplicate the DB design.
In other words: you should just have 1 SQL DB, multiple tables. Design the tables and columns appropriately using the right data types, and ask ChatGPT for help if you're not sure which data type to use.
Avoid:
- Multiple DBs, NoSQL, and any kind of premature optimization. Worry about 1 million users/visits problems when you get to that level, and even at that level modern RDBMS software can handle that kind of load on a single DB server.
- MongoDB and non-relational DBs. Mongo tends to lie about what their databases can handle despite fancy "transactions" marketing on their site
If you don't believe me, note the no less than 5 separate studies (!) into how Mongo loses writes and experiences other problems you really don't want to have to think about: jepsen.io/analyses
To be fair, these studies are slightly old and it's very possible they've been addressed by now, but Mongo has been guilty many times of misleading marketing practices. I wouldn't place my trust in this kind of entity.
Instead, use and learn:
- Very well known and tested databases where experts have verified their behavior properly so that you don't have to worry about unexpected surprises in production. PostgreSQL and MySQL are both good choices for this reason.
- SQLite is also OK to stick with, but you might have to think about extra things like restoring the DB from a backup if the server dies. I'd advise just using any "database as a service" provider like Amazon RDS and picking Postgres/MySQL as I mentioned - Amazon has a free tier, handle automated backups and persisting data for you so that you don't have to worry about it.
Hey @ben, Thanks for the detailed replied. Its very useful. I've made up my mind, and I want to stick with sqlite for now. Until, I've something good. I want easy things to get started and want to convert my ideas into reality.
Anyways, thanks for the help.
That is the reason I historically stayed away from Mongo but they’ve improved and either way, I need a document store (jsonb in PG won’t do).
Newbes can use Mongo, Marc Lou has built 20 startups on Mongo and makes 300k. He was very novice when he started.
Fair play if they've fixed the issues
I'm curious what kind of use case you have where jsonb won't work considering Postgres typically benchmarks well (ironically, better than Mongo) when dealing with jsonb data
And yeah I'm not saying it's not possible. You can be successful with any DB choice really and Marc's use cases work fine with Mongo (I don't know all of his apps, but most of the ones I've seen either don't have persistence requirements or have pretty simple data models that can basically be stored in anything including Mongo), but I typically don't recommend Mongo to new people because I've seen a lot of folks shoot themselves in the foot trying to force relational data into a document format just because they don't know any better
What I mean by that is that it's really easy to look at Mongo if you don't have a lot of experience and think "oh yeah, I can represent everything I could ever hope to store in a database using a JSON doc" even if there might be relationships between entities that are better off in a typical RDBMS and not a document DB. I mean, I've seen people do wild shit like attempt to represent an entire social graph for a user in a mongodb document. That's where the danger is in my view.
Why I had to go to Mongo: I really needed something that was "json first". I got 3000 different fields/keys, but my largest documents only have 100 fields at most. So a huge number of the fields only appear in a sub-set of the documents.
True Marc's use cases have simple requirements, but that is true for most newbies. In a way I'd say Mongo is better for newbies doing simple stuff than experienced engineers building complex apps...
Lol, @marc is this a feature, or a bug? Three consequitive dashes seems to make text an MD header, or similar?
Wonder if it's just the Markdown parser doing that
Even works with two dashes, from what I can see. Maybe even one.
Yeah, seems to be there is a case of MD injection here, which if true, might be possible to lead to an MDX injection, at which point your cookies are mine ;-)
😱
That was a Markdown feature we shouldn't support. Fixed now
Pretty interesting discussion going on here!
I’ve been using Mongo (via Mongoose) for a while and I tried SQLite recently.
I like SQLite for the standardised way of building databases. With MongoDB, there’s no real best practice and everything is open to interpretation
Yes exactly. And sometimes your data looks exactly like that, which makes it hard to retrofit into SQL.
It does. Best not to change database types midway into the project anyway