I'm replacing my PostgresDB with MongoDB. How fucked am I?

I'm replacing my PostgresDB with MongoDB. How fucked am I?

Other urls found in this thread:

postgresql.org/docs/current/static/sql-explain.html
twitter.com/AnonBabble

If you assume your fucked, why migrating at all?

If you're making that decision then it means that the DB is not important, therefore you're not fucked

>How fucked am I?
Proportional to the time elapsed since the last backup.

Because I need to hammer realtime data with 60 messages / second / user into the db and ther is no way im going to do this in SQL. So it's MongoDB or redis and with redis I would have a second data storage (that doesn't persist) besides the DB that needs to be maintained.

its fine if your system doesnt need structured data

unironically using mongo software

>migrating from a relational db to a document based db

I seriously hope that you don't need any of the traditional SQL functionality, because if you do, you're going to have a really bad time.

So only part of your application needs Mongo. I would definitely only use mongo for what you need it for. I would not try to move an entire schema from a relational to a nosql database. You're going to have a bad time if you do.

Postgres can handle a shitton of json based noSQL stuff nowadays and very well, plus all the advanced indexing, joins, sharding, validation and other features are all there if you decide to use them down the track.

you're literally falling for a brainlet javascript hipster meme.

>mainting 2 database is easier than 1 database

I think I might just re-write everything dude

>maintaining a database is hard

Maybe you're not, but your frontend engineers are. Because you're basically making all of the projecting/filtering/etc. functionality their responsibility. Which, as everybody knows, is an antipattern.

Go with redis. And remember that in no way your project is going to be successful if you're tying yourself to only one technology - use the best tool for the task. It's not that hard to maintain 2 or even 3 databases especially considering that each of them would contain only part of your data.

>frontend engineers are
tfw I'm the frontend engineer and I want to use Mongo only for the frontend (actually in the middle end, the Node.ja Server has mongo and is serving the frontend), SQL will be used in a C# backend.

> It's not that hard to maintain 2 or even 3 databases especially considering that each of them would contain only part of your data.
I would have 2 databases, one for persisting backend data in C# (heavy load calculation results from cuda), one for persisting fronend data in Node.js and then I would also have redis for frontend data that is very fast and ephemeral. But I think this fucking sucks. It's simpler to start node.js, request init data from the C# backend, load it into mongodb and then use mongodb to store all frontend data.

How wrong am I?

You're not fucked at all. MongoDB is web scale

Very fucked. MongoDB as a steaming pile of horse shit

Well, one is a DBMS and the other is document based NoSQL.

Hopefully you've planned and aren't just on the hype train

Postgre can handle that. Something about your system architecture behind the application might be suboptimal if you cant hit that threshhold

"web scale"; lol.

Hardly. Sharding in mongodb is a total nightmare. You can SEE that it wasn't built for it.

If you want "web scale" use an actual scalable database that was built to scale from the start: ES, couchbase, etc.

Shards are the secret ingredient in the web scale sauce. They just work.

Except when you have to manually manage them (like in MongoDB).

If that's what they need to do to get those kickass benchmarks, then it's a great design.

Not really wrong at all. My old internship was running a project where they kept some legacy stuff on a MySQL db and the rest on a couple Mongo ones. It helped us keep track of stuff, especially me the dumb ol' intern who knew not to touch the production db unless corporate came in and asked for specific stuff.

OP, I wouldn't worry about it a lot, but as mentioned before my post be prepared for several calls from your frontend guys bitching about this function or another not being available to them.

only 60 per second?

postgresql is faster than mongodb man.. the databases are completely different moving one to the other is a nightmare

I suspect OP has an undiagnosed bottleneck in the system architecture design. More than likely, either language driver inefficiency or subpar input filtering that compounds computational complexity.

OP, you need to profile what ever it is you're making through and through. Start with your schema, queries, and then the code surrounding SELECTs and INSERTions.Otherwise input sanitation can be computationally complex

yea it's a different issue not the database

OP try to use:
postgresql.org/docs/current/static/sql-explain.html

do like "explain analyze select blah blah"

see if something can be greatly improved. sometimes queries are a lot slower than you think they are. sometimes it's faster to query something twice rather than join somethings etc
weird things like that happen all the time