What surprises me is that so far none shoehorned Postgres on top of FoundationDB.
I'm not familiar with FoundationDB. What benefit would that give Postgres?
Goodbye MongoDB, Hello PostgreSQL (2015)
21–30 of 172 posts
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#22I used both NoSQL and SQL databases. Proper replication topologies (e.g. multi-master configurations) and JSON columns killed the NoSQL movement. I'm glad the NoSQL movement existed and forced the SQL camp into out-of-the-box thinking, but I wouldn't go for any NoSQL solution today on a greenfield project.
Is there a proper replication topology that guarantees all writes survive single node failures e.g. in a 3 node cluster and and reads also as expected? i.e. any sequence of reads and writes execute correctly in any single node failure scenario?
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#23I still feel somewhat that Mongo is blamed for things that it is not supposed to do. Removing millions of records surely is not a usecase that Mongo is comfortable with. Or if you absolutely need a schema to protect developer doing silly things, then traditional relational database is surely way to go. Mongo is superbly quick to serve read-heavy applications. I did one project with Mongo & Sinatra and the app was abl…
> Or if you absolutely need a schema to protect developer doing silly things, then traditional relational database is surely way to go.
Then you should use a relational database every time, because all developers "do silly things".
I've seen this same argument against strong types: I don't need them because I don't make mistakes.
You do. So does everyone else.
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#24I used both NoSQL and SQL databases. Proper replication topologies (e.g. multi-master configurations) and JSON columns killed the NoSQL movement. I'm glad the NoSQL movement existed and forced the SQL camp into out-of-the-box thinking, but I wouldn't go for any NoSQL solution today on a greenfield project.
What if you didn't need relational queries and was dealing with a large volume of data that needed to be sharded?
There are plenty of modern, distributed RDBMSes that make sharding transparent to the user (E.g. cockroachDB, yugabyte, vitess, many cloud offerings, etc.). Most NoSQL databases end up adding transactions because they are important, and thus the scale advantages for NoSQL systems over relational databases are diminishing, if remaining at all.
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#25I used both NoSQL and SQL databases. Proper replication topologies (e.g. multi-master configurations) and JSON columns killed the NoSQL movement. I'm glad the NoSQL movement existed and forced the SQL camp into out-of-the-box thinking, but I wouldn't go for any NoSQL solution today on a greenfield project.
What if you didn't need relational queries and was dealing with a large volume of data that needed to be sharded?
To me, "warm" (not hot) data falls into one of two boxes:
- schema on write: You know what future queries you will ask. Use SQL.
- schema on read: You don't know what future queries you will ask. Use object storage.
Of course, in practice, part of your data will be schema on write and part on read.
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#26Previous discussion from 2015: https://news.ycombinator.com/item?id=9178773
The top comments of this old thread are retrospectively hilarious because sone frontend guys argues about wether SQL is not easily composable and exchanges trick about how you can securely and dynamically concatenate SQL statements. But nowhere to be found is the concept of prepared statements that would gracefully help then write nicer code. https://www.postgresql.org/docs/current/sql-prepare.html And that is a ligh…
Correct me if I'm wrong, but I think you missed the point of the discussion? It is not connected to frontend at all. It talks about the difference between using an ORM versus constructing SQL statements directly, as strings.
In that light I don't think `PREPARE` and stored procedures would help much (or at all).
I also don't find them hilarious, though they do represent very extreme views on the subject (imho) while to me it is essentially a tradeoff (I use both direct SQL and ORMs, depending on the needs of the project).
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#27These articles never get old. Hey we picked solution A and realized that it has some cons not only pros and now we are moving to solution B that only has pros. Few years later there is a new article, hey we are moving to solution A|C because...
I've never seen an article about switching from Postgres to something else. Obviously Citus, Timescale, and other Postgres forks don't count.
Uber did one a while ago, but tl;dr they didn't really understand Postgres very well and were dealing with unique problems.
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#28Earlier quoted context omitted.
What if you didn't need relational queries and was dealing with a large volume of data that needed to be sharded?
If you just need a key-value store, a database like MongoDB is rather oversized. Redis or and a bunch of object storage system (now that they actually include locking) are much easier to operate. As soon as you're back to needing complex queries (with or without relations, Postgres it is again.
Redis is an in-memory datastore first and foremost (with optional persistence). With that said, it's probably not the right tool if you need to store and persist TB-worth of data even if it is key-value. Something like Cassandra is probably a better fit if you have a lot of non-relational data that needs to be persisted and you need it to scale.
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#29I use MongoDB as a front-end that does full-stack prototypes from time to time in Node, and it's great using javascript from start to finish, you don't have to switch mental gears, so creating an MVP it's fast... but.
Sometimes I feel like I'm just avoiding SQL for no reason, not using any of the advantages of NoSQL, and only using Mongo as a SQL-wannabe with a shoehorn like mongoose.
I wonder how many MongoDB projects out there are just using Mongo because it's the trend (something like MEAN / MERN) and not because makes sense. Like there are out there a lot of SQL ORMs for node that, do the same job and better.
Don't get me wrong, I love MongoDB for a lot of weird stuff (like web scraping, CSV files, and archive data), but I feel a lot of the hate, it's because a lot of devs (myself included) have developed projects, that could be working better with a old fashion relational DB.
Re: Goodbye MongoDB, Hello PostgreSQL (2015)
#30MongoDB is like snapchat for database
this was funny, but I think its a lot better now. Imo rolling their own consensus protocol was a terrible idea, but they are using Raft now I believe.