1. 6

  2. 5

    If I ever thought I might need the benefits of NoSQL, I would begin the project with PostgreSQL then start to use its NoSQL features after the need for those benefits started appearing.

    1. 4

      You can index into jsonb objects already! That’s sometimes all you need.

      1. 5

        Be aware that PostgreSQL doesn’t gather statistics for jsonb columns, so despite having indexes it can generate pretty bad plans in some cases. Always check your query plans :) I wrote a detailed post about my experience with them

        1. 2

          Ooh, good point. If you really need solid planning, might want to use a generated column instead?

        2. 4

          jsonb with proper indexing is my favorite Mongo replacement.

          If one were really, really kinky, one could probably implement support for Mongo queries using plv8 with the appropriate side-loaded helper script. If you only one had a parser.


      2. 7

        I hate to ad hominem this place up, but these are the same people who wrote that truly atrocious article on Vim and IDEs, so I’m hesitant to take any of their claims at face value.

        1. 4

          This one is not good too. “Some people have millions of rows in the database, so they have to go NoSQL route”. Yeah, no shit. I have billions of rows in some tables (with a sizeable churn) and Postgres looks pretty happy to me and can easily endure so much more.

          Also a bit about “flexible NoSQL”… there is another comment on the top level that goes into more detail.

          1. 2

            It unfortunate that they seem to have such inconsistent quality for a site that was originally intended to separate the wheat from the chaff in terms of answers to programming questions. There are many issues with that approach, the site, the community, and there is a need for all levels of content - but, more editorial control might be good on the blog.

          2. 4

            Rick Houlihan, AWS’s DynamoDB expert who gives really good talks about NoSQL, really stresses that the key mistake made with NoSQL is designing the system around RDBMS concepts

            It’s interesting to see the flaws in this article after watching his talk: there’s a huge focus on what seem to be the wrong things (“flexibility”, database size - who cares, NoSQL means optimizing for compute over storage) and less on modeling your data to make a NoSQL system work for you.

            1. 3

              First, we have to remember that NoSQL databases are probably great for Amazon and Google but not so great for your side hustle. The performance benefits become more obvious the greater the scale of your database.

              There’s a lot of truth to this. Most of my employer’s [Couchbase’s] business is with big enterprises like Disney, Apple, eBay, Adobe, etc. I’m a client-side programmer, and the scales these people are operating at boggle my mind. But at the developer-community level, like here on lobste.rs, Couchbase is unknown or “I thought it was CouchDB”.

              But there are two other areas I think NoSQL, or more specifically, document databases, work well at:

              1. Distributed systems. I mean really distributed, not just a server cluster. (This is my area.) Here transactions are borderline impossible unless you’re Amazon or Google with atomic clocks attached to every node. And strong schema become a problem, because there’s no way to do an atomic schema upgrade across all the peers. Sure, you can use a relational db under the hood, but then you need a big adapter layer between it and the sync logic. A document database is better at dealing with sync.
              2. Really small projects or prototypes. It’s a lot easier to build something quickly using flexible data formats instead of a rigid schema, and it’s simpler (I find) not to have to switch into a separate language like SQL to express queries.
              1. 2

                I mean, the problem of essential complexity doesn’t go away because you can write your backend in JavaScript. Hard problems remain hard, and engineering is the art of maneuvering through an n-dimensional solution space to find anything that advances your goals. If that is Mongo, OK. But the idea that there’s something essential to NoSQL that means it will “win” is just marketing bafflegab.

                1. 1

                  Another great (!) article from the StackOverflow blog, who have previously also talked about editors and presented Vim and Emacs as unusable. The solution to sharding is not to introduce a datastore which doesn’t have a proper schema and any sort of relation, it is fixing the existing databases. The lack of a schema is listed as a good thing, but it becomes a nightmare if you have an existing application. Adding new things to the application that can use non-existent keys means either adding doc.value || "" everywhere, or re-implementing what SQL does for you with default values anyway. Additionally, as the article mentions, lack of joins means that you will have to embed related data within the row, which leads to duplication and bloated stores. Now, I completely agree with the sentiment that creating indexes is hard and it’s hard to properly optimize a database, but that doesn’t mean we should just throw our hands up in the air and just embed related data in each row (duplicating it in the process).

                  1. 2

                    Another great (!) article from the StackOverflow blog, who have previously also talked about editors and presented Vim and Emacs as unusable.

                    That article was particularly terrible. Citing it as support for this one doesn’t really bolster any confidence in me that this one is any good.

                    1. 2

                      To clarify, this article doesn’t cite that one, it’s just by the same authors.