35 ms·

Have the Tables Turned on NoSQL?

• beckingz 6y ago
  yes.
• asdfasgasdgasdg 6y ago
  A while ago I'd say! Last time I heard anyone seriously excited about NoSQL was several years ago. It still has its place, but it seems like Postgres is the hype these days.
  • symlinkk 6y ago
    Weird to describe an open source relational database as “hype”. It’s the assumed default. It’s like describing water as “hype”.
    • TedDoesntTalk 6y ago
      > It’s the assumed default It is now, but before it had that privilege, MySQL did. The hype he is referring to may have taken the crown off MySQL and given it to PostGres. But make no mistake....postgres is not water. How do i know? Because it, too, will one day be unseated. And water does not lose its crown.
      • smt88 6y ago
        I think Postgres is popular because of its emphasis on being explicit, strict, and correct. We're seeing the same thing in programming language adoption, where TypeScript is exploding in popularity and seemingly every language is getting static types if it didn't already have them. To me, the rise of Postgres (and its spiritual siblings, languages with expressive, static type systems) are about maturing of the industry rather than hype.
        • joshxyz 6y ago
          > I think Postgres is popular because of its emphasis on being explicit, strict, and correct. And good documentation. Very good documentation.
      • 7thaccount 6y ago
        I think you have to look at it less as Postgres and more as SQL vs NoSQL. SQL has been the default for eons, (although I still use a 70s era heirarchy based database on a daily basis), but that is another story. My company has dozens of large production scale databases and I think only one or two NoSQL products. We don't use Postgres unfortunately though. NoSQL went through a hype in some circles (stayed non-existent in mine for the most part), but in my eyes, SQL has always been the work horse and was never not the default in the greater industry in my eyes. The Postgres implementation has become pretty popular recently, but so has Oracle and others in the past. I think the commenter was getting at this.
        • TedDoesntTalk 6y ago
          > 70s era heirarchy based database on a daily basis Your file system perhaps?
          • 7thaccount 6y ago
            No haha, a real database as part of a major product. It's cool in a way, but very frustrating compared to SQL. I guess the closest thing people probably could compare it to is the MUMPS running in hospitals.
    • LukeShu 6y ago
      Fitting comparison; it's been weird watching the rise of reddit.com/r/HydroHomies . We live in weird times, if water can be "hype", so can PostgreSQL!
      • zikzak 6y ago
        I had to check. It's really a subreddit.
      • rubatuga 6y ago
        That subreddits name had an interesting history if you google it.
        • CameronNemo 6y ago
          https://knowyourmeme.com/memes/sites/water-niggas-hydro-homies https://knowyourmeme.com/memes/sites/water-niggas-hydro-homi...
      • CameronNemo 6y ago
        I always think of Heinlein's water brothers when I see that subreddit.
      • darkerside 6y ago
        It is fitting. Water is a miracle drug. And we take it for granted. Needs more hype!
  • random5634 6y ago
    Yay - I dodged the noSQL hype! And agreed on postgresql (and sqllite if something small and simple needed without any overhead)
  • schoolornot 6y ago
    I'm surprised Postgres has continued to be popular despite having multi-master or sharding support.
    • zozbot234 6y ago
      Postgres supports table partitioning and foreign data wrappers (used for accessing remote SQL databases) which can be used to set up sharding as described in the postgres docs.
    • markdown 6y ago
      > multi-master Wow, so oppressive. #DecoloniseSQL
    • sitharus 6y ago
      Why? Very few products need sharding, let alone multi-master. Sure a popular social media platform would, but most development in the world is for small to medium scale line-of-business apps. Postgres is _fantastic_ for these.
      • plaur782 6y ago
        This is the key point we see - most applications just do not generate write traffic that is beyond what a recent release of Postgres can handle.
    • speedgoose 6y ago
      It's because most developers don't need multi-primary databases, which have downsides too.
    • sharadov 6y ago
      I manage a large sized Postgres farm with 100s of instances, and there has been one case where we need multi-master, and I went with Galera cluster for MariaDB. You can shard using the citus extension for Postgres.
      • plaur782 6y ago
  • petters 6y ago
    The excitement about NoSQL at Google seems to have stopped with the introduction of Spanner, at least.
• barnaclejive 6y ago
  yes.
• codazoda 6y ago
  Each has its place. Three years ago I started a new project and elected MariaDB. I was coming from a project that was using MongoDB. Because the new project seemed to have very structured data, mostly coming from third party systems, I opted for a structured solution. Three years later and my structured database has tons of tables and requires lots of brain twisting joins. It slowly evolved this way, while our UI basically evolved to use a single React "state" to represent an "order". It's tempting to consider what it might be like to store an order as a single Mongo document and forget all this structure.
  • ramraj07 6y ago
    This never made sense. How can you forget the structure? Either you code the Structure in the schema or in random places in your code as dictionary keys, which seems far more unwieldy.
    • codazoda 6y ago
      I used to agree, but this project feels different. I don't think it would require much structure in my system. I just deal with a single order. Then, I take pieces of that and send it out to a couple 3rd party API's. Those API calls are structured, sure, but so is a document. I only load orders by their order number and then deal in the order as a whole. My joins are primarily to pull in all the pieces I need for an order. Maybe this is just my current, "the grass is greener" view, but I wonder.
      • paulryanrogers 6y ago
        Postgresql has JSONB if the data isn't too dense. Then again there's also the file system.
  • CharlesW 6y ago
    > Each has its place. NoSQL encompasses many, very different types of databases. Were you thinking about document-store DBs here?
• EhhhhSql 6y ago
  This same article could have been published in 2011 with different headings. In fact, it almost seems like they intended to publish an informational article and some editor came in to write some headings likely to inspire some hot takes in response. When was the last time you heard someone seriously say that "NoSQL"—that's right, don't even name a database or name any characteristic of its operation, how it scales, how it's queried, its consistency guarantees, its maintenance overhead—is easily comparable to a vertically-scaling SQL engine? The whole rhetoric of tables turning implies that you'd choose a database for cultural reasons outside of hiring ability.... who thinks like that?
• TedShiller 6y ago
  Yup. Told you so.
• shrumm 6y ago
  Honestly, I think the more important takeaway isn’t the decline of NoSQL. As the article says, it’s the conclusion that’s what’s good for FAANG isn’t necessarily what’s good for your average project. I know this sounds obvious but it’s been a constant source of frustration for me with the hype train. You could apply the same logic to a whole bunch of tech like Kubernetes, service mesh etc etc and arrive at the same result. Every tech has a trade off, understanding it is critical. Don’t pick tech spot SOLELY based on FAANG use.
  • hooloovoo_zoo 6y ago
    Sometimes engineers have perverse incentives. If you want a FAANG job, it probably helps to have experience with FAANG tech, even if your current company doesn't need it.
    • ehnto 6y ago
      It is a very frustrating industry to spend a long time in. A hamster wheel of constantly shifting goal posts for mastery. I wouldn't mind if they were fundamental advances in software development, but it's mostly the same stuff with small advances but massive learning curves of arbitrary, non-transferrable minutiae. The side effect of this ever shifting tooling set, is almost no one masters anything. All software is varying levels of crap written by newbies, because when the tools change every project you are always a newbie in that tool set.
      • llbbdd 6y ago
        As someone at a FAANG company right now, your second paragraph neatly identifies a core frustration I have with my job that I haven't been able to articulate before now. Might be time for a change...
      • kqr 6y ago
        > I wouldn't mind if they were fundamental advances in software development, but it's mostly the same stuff with small advances but massive learning curves of arbitrary, non-transferrable minutiae. I think this is pinpointing the key exploitability in the market. If you have seen enough tech come and go, you can figure out which 98% of this year's idea are the same as the year before, and 40 years ago. At that point you can start cutting through the bullshit and design things using brand new tech as if you had used it for 20 years already. At that point you're way ahead of the rest of the pack. (And you can choose not to use the brand new thing, and argue convincingly for why the almost-exactly-the-same 30 year old, more mature and stable, tech is better.)
• chadcmulligan 6y ago
  NoSQL was the last time I ranted about a stupid technology that became popular, nice to see its finally being put to death publicly. I just ignore them now and wait for their inevitable death (node.js I'm looking at you) Edit: was just thinking the defining characteristic of these sorts of technologies is they are advocated as replacements for things that already exist, and the people advocating them are not experts in the things they are trying to replace. So they don't understand the reasons behind why things are done - NoSQL was obvious for any database person - no transactions, no normalisation. Node.js - tries to replace server coding with something vastly inferior, and it sort of works until you need a proper server. Edit2: lol, time will tell
  • ian-g 6y ago
    It might be a silly question, but when you say you're waiting for node.js to die, do you mean node specifically or server-side JS?
    • chadcmulligan 6y ago
      I think the only reason you'd use server side JS is you don't know C or C#. I'd be hard pressed to imagine someone who knows a number of server side environments and languages choosing JS as the solution - strong typing and performance are the obvious possible problems, then multi threading performance etc. The only reason anyone uses JS is the browser constraint, remove that and there are a lot of better solutions.
      • knicknic 6y ago
        There are, but not with as many developers as JS. And because JS has so many developers it is better in some metrics.
      • mb7733 6y ago
        I'm not going to stand here and say node is the end all be all of server side languages... but you really can't think of a reason that one might choose node over C for writing the back end of a web app? I'll reverse it and ask: Why would you want to write an app to serve some CRUD API in C? This isn't and has never been a very popular choice.
• legerdemain 6y ago
  This blog post is calling at least two different things SQL, and it's kind of infuriating. SQL as a query language is never going away. Virtually every database has found it necessary to offer a SQL-like query language: Cassandra's CQL, HiveQL, Couchbase query language, and so on. SQL is a human-readable, composable formalism for describing data. What's gone away is the practice of writing complex, highly linked, normalized database schemas with layers of constraints and foreign key references. That was banished to the land of stagnant enterprise 10 years ago and is not coming back. The last 10-15 years have been an evolution from mostly static, deeply linked, highly structured data to shallow schemas, append-only updates, denormalized data, and stream processing. If you data is a stream of updates, there's not as much pressure to roll back. If your data is mostly defined by a series of processing pipelines that live entirely outside your data warehouse, there's not a lot of upside on enforcing constraints in the DB. If anything, we have learned that it's very useful to offer different denormalized views of the data in the DB to different consumers. MS SQL Server is not roaring back. Businesses have just learned to unbundle data processing from data warehouses. Data warehouses now have fewer tasks to focus on, such as scalability. And if your DB is just a dumb replica with a flat schema, whether it's an RDBMS or not is pretty unimportant.
  • CharlesW 6y ago
    > This blog post is calling at least two different things SQL, and it's kind of infuriating. For better or worse, that's not what "NoSQL" means. I understand that the name is a bit infuriating, and I personally map it to "non-relational" as I read. > What's gone away is the practice of writing complex, highly linked, normalized database schemas with layers of constraints and foreign key references. This may be true for some use cases, but in general that's wishful thinking.
    • jolux 6y ago
      There still seems to be a decreasing amount of appreciation for the relational model and the power of SQL databases to maintain data integrity. I'm not quite sure why because relational databases are a uniquely powerful tool in software engineering.
    • 6y ago
• falcolas 6y ago
  Nah, the pendulum has just swung back in the opposite direction. Give it 10 or 20 years, and just like strongly typed programming languages, NoSQL will be all the rage again, and you'll be "an idiot" for not using it, again.
• dazhbog 6y ago
  So glad I migrated to SQL recently. I thought I had unstructured data and I had no real need for relational data. But oh boy I was wrong. Want a customer list, billing, emails, linked accounts with those users, etc. All of this was such a pain in mongo and remnants of messy schema still lurk in our codebase. Reminds me alot coding in typed languages like C vs. python or JS. But in the case of mongo I think I was getting the worst of everything ;)
  • xwdv 6y ago
    I think the reason this happens is people have a poor understanding of what is unstructured data. Most data is going to have predictable structure to it, so you might as well just make it official. In fact, in all my years, I don’t see any real reason to use MongoDB over SQL, unless you’re storing log files or something.
    • atom_arranger 6y ago
      I’ve been thinking lately that maybe the most reasonable path would be using SQL early on so you have a very clear picture of your schema, and you can do migrations easily. Once you scale up and your schema and access patterns have solidified then you can make the switch to NoSQL where it makes sense.
      • mercer 6y ago
        I suppose it depends on the specific project or feature. Usually I go for the approach you describe. But more than once I got bitten by doing this for a feature or project where things were still very much in flux, and/or in a prototyping phase. In those cases, starting with 'NoSQL' (JSONB columns in Postgres though) would've saved me a lot of trouble, and it would have been much easier, relatively speaking, to migrate my data into proper tables once things solidified. Still, I do find that going for 'SQL' by default has usually been the better choice.
  • joshxyz 6y ago
    This this this. At the sight of the first relational data I noped the fucked out immediately at nosql db's
• redwood 6y ago
  This is filled with incomplete information. MongoDB has had transactions since 4.0 and a strong consistency model by default from the start. That's not to say they didn't have some bad defaults early on... This article makes gross generalizations and just doesn't really add all that much value. Document databases offer a full-featured general-purpose alternative and really shouldn't be compared to Key/Value stores at all. They're only being lumped together since both are "nosql", a fairly tired term at this point
  • tomnipotent 6y ago
    It's a really bad article, just filled with gibberish starting with its description of SQL and NoSQL. Fortunately the comments here will provide better material.
  • erik_seaberg 6y ago
    https://jepsen.io/analyses/mongodb-4.2.6 https://jepsen.io/analyses/mongodb-4.2.6 reports the default read and write concerns were extremely aggressive, and even the safest available values had issues.
• RcouF1uZ4gsC 6y ago
  One thing that I think is going away is eventual consistency at the application layer. It is too much of a technical debt and error prone for most applications. It is much easier to reason about a consistent database. And systems like Google Spanner, and CockroachDB show that you can have a consistent database with good scaling and good performance.
• jabberwcky 6y ago
  Fashion-oriented posts like this are always a shitfest, and this one is no different. It is setting up a variety of different architectural styles as if they were in competition for the "top spot", which is to say the only option that should be applied in all use cases. This isn't just garbage, it's actively encouraging a whole breed of shitty engineers who never learn how to approach solving a problem. > The goal of a NoSQL database, on the other hand, is to ensure ultimate scalability by making sure that the data is stored in a format that can be shared—or sharded—across multiple servers From here, it then proceeds to list architectural specialisms that have absolutely nothing to do with scaleability - "Document stores" excel at managing compound representations of data, they do an amazing job of minimizing IO when many small sets of (usually hierarchically structured) data can be stored as a single unit. Document stores map particularly well to the "REST" service architectures in the original Sam Ruby meaning of the word - Graph databases are (usually but not always) document stores that excel at indexing and executing transitive queries. Their innovation is not in storage, but in querying particular kinds of data sets with complex (and possibly undefined upfront) relationships using queries that are also likely complex and possibly undefined. This has more to do with expressiveness than scaleability - Column stores excel at managing timeseries. Like document stores, their entire point is IO and processing optimizations that become possible when data is in a particular shape -- varying with a particular profile, and with high redundancy when viewed along a single (usually time) axis. Column stores absolutely rock when applied to the right kind of data -- they can provide 20x storage size improvements and similar query execution time improvements. Finally we can say that column stores have something to do with scaleability. A 20x improvement in hardware utilization could very much be make or break for many kinds of common project - Time series databases are column stores. > Because companies like Google and Amazon created these databases for their own massive data stores, the goal was to reduce the time needed to grab a piece of data Every. Single. One of these architectural styles long predates the FAANG-industrial complex. > NoSQL databases don’t offer much in the way of transaction management or real coding Real coding? > NoSQL databases like MongoDB just take data and store it Nobel Prize stuff right here. I stopped reading
  • redwood 6y ago
    I got a good chuckle out of "real coding" too
• ccortes 6y ago
  I don't have much experience but you can easily mess up both SQL and NoSQL. I recently picked up Datomic and honestly I'm not looking forward using SQL again for a while.
• paulgdp 6y ago
  I'm surprised that this article is not even mentioning one NewSQL DB like: - Google Spanner - CockroachDB - TiDB - YugabyteDB - FaunaDB Can it be that those are so little known by most developers?
  • vvern 6y ago
    FaunaDB is NoSQL, it’s transactional, but NoSQL nevertheless.
  • kthejoker2 6y ago
    Who needs this kind of scale besides FAANG-like companies? Why would you start some garage SaaS with YugabyteDB?
    • BossingAround 6y ago
      > Why would you start some garage SaaS with YugabyteDB? You know, I never thought of it that way, but it does sound kind of funny actually. I'm sure you could get away with starting your garage SaaS with MongoDB though, so maybe why not...?
• Kaze404 6y ago
  I have a very antagonistic relationship with NoSQL databases because the vast majority of people get nothing out of using one, and yet every resource a newcomer to programming (on the Node.js ecosystem at least) recommends using MongoDB with Mongoose (an ORM for a NoSQL database? Why?), leading them down a path they really have no business walking because they could have instead learned the widely used, time-tested traditional SQL databases.
  • dlvktrsh 6y ago
    I've been the exact person you're talking about, do u think I should switch to postgres instead? I'm trying to build an Instagram bot that collects all sorts of user metadata and their interactions with other users maybe evern someday make a Twitter version of the saem bot and try to mine some more data
    • petersellers 6y ago
      For small projects like this either one would probably be fine. Hell, you can try implementing with both just to see what you like and don't like from each.
    • Kaze404 6y ago
      I don't think you'll benefit from switching either way, but in my opinion you'll benefit from learning Postgres when you have the time / start a new project.
    • mercer 6y ago
      I suppose switching depends in part on how much work that would be. That said, I tend to pick Postgres as a default because using JSONB columns I can get the benefits of 'NoSQL' and switch over to 'SQL' while staying within the same database.
  • ZephyrBlu 6y ago
    > and yet every resource a newcomer to programming (on the Node.js ecosystem at least) recommends using MongoDB with Mongoose (an ORM for a NoSQL database? Why?) It's because it's easy. Who cares about thinking? Just throw your data into Mongo and it'll work (For your toy project where nothing matters). It's sad to see that there's such a massive lack of the type of attitude described in this article: https://www.norvig.com/21-days.html https://www.norvig.com/21-days.html.
• herodoturtle 6y ago
  Interesting blog post. Thanks for sharing. This part, in particular, resonated with me: > Querying data is a little harder. Apache’s Cassandra uses Cassandra Query Language or CQL which, interestingly, does not allow for joins. MongoDB just sends JSON objects in reaction to requests. Need all users in Ohio? MongoDB sends a big chunk of data. I fondly recall the late night debates with fellow colleagues in the industry, several years ago, when we were pitching a database design to a startup bank in South Africa. Back then during those fights some even suggested that the NoSQL vs YesSQL debate was a religious war - much like vi vs emacs - but in the case of data storage it quickly became obvious that each philosophy had its respective strengths and weaknesses - which were in turn easy to understand, to sell, and to add value with. But nowadays I must confess I do not know of many shops using NoSQL, and I suspect it is for the reasons quoted from the blog post that I shared above. I would love to read your insight if you've been part of a big NoSQL deployment. We struggled to sell it, so I suspect we must have missed out on some interesting opportunities.
• hyperpallium2 6y ago
  Why did NoSQL become popular? Was it the huge datasets required by the internet? Before SQL, there was already no SQL. I don't mean that as a semantic joke, but that databases existed before relational databases that were faster. Relational DB were too slow to even be usable, until B-trees made them barely feasible in performance (and still much slower than previous DB). The advantage was flexibility: you could change the database organization without having to rewrite application. Similarly, if your application needed data in a different form, you could make it seem that the database was already in that form. So SQL was like a glue between systems that could transform the structure of the data - much like high school algebra can put an equation into a different form, that is equivalent but more convenient. I can imagine, that back in 1970's, computing power was growing much faster year-by-year, than typical database sizes were. So, although "slow", they became "fast enough" for more and more use-cases. But in 2010's, internet datasets were growing much faster - and computing power wasn't. So Relational DBs weren't "fast enough" for these cases... hence "NoSQL". Is that about right?
  • overcast 6y ago
    NoSQL rocketed in popularity, because it required zero working knowledge of how databases work. You could get up and running on a project, without having to worry about what tables, columns, and their relationships to one another meant. You could throw ANY data in, and generally get it back out.
    • sharadov 6y ago
      Exactly! Developers did not want to learn messy databases. I think a lot of folks without experience entered the industry ( mostly from boot camps and such and ruined everything)
    • dodobirdlord 6y ago
      I think that's not the reason. NoSQL rocketed in popularity on the back of adoption by a few large companies with scale problems that had to abandon relational databases due to scale issues. If the requirement is to serve very high low-latency throughput to back something like shopping on Amazon, then relational databases and SQL in particular aren't very helpful. You know your data access patterns up front, and can optimize your database to support exactly your API's access patterns. Ad hoc queries on the production database are prohibited, data analysis work gets done with some kind of ETL pipeline, and the choice to trade off any part of ACID for more throughput and lower latency is a no-brainer.
• kthejoker2 6y ago
  It is fractally amazing to see the exact same false dichotomy within data stores, DBMSes, and query engines themselves playing out in the "market view" of those same products. That is: The tradeoffs between all these systems has always been the effort required to create, modify, and maintain well-groomed (albeit rigid) schemas and data models versus the speed, scale and agility of a schema-on-read / "unstructured" data storage mechanism. Which is then counterbalanced by the tradeoff between getting quick, accurate (albeit rigid) answers of a well-managed data warehouse vs. having to string together fragile, complex ad-hoc wrangling and querying code. So pick your poison: a junk drawer full of Legos or a beautiful sculpture with the head and an arm missing. And the obvious answer is for most organizations you need both! Agility for bottoms-up discovery and exploration, and rigidity for top-down hard facts and shared objectives. (Maybe it's a lakehouse, maybe it's not, TBD.) And then there's this meta thing where NoSQL was pitched as a disruptor, agile, low barriers to entry, and RDBMSes and data warehouse vendors got this reputation as slow, rigid, too in love with their creations to change ... And now there's this reverse pushback - oh, actually these NoSQL vendors need to grow up and mature their products, that agility was just a lot of hype and chaos, these data warehouse vendors had the right ideas, they've learned to play the NoSQL vendors' game better than they have and their go-to-market strategies have stood the test of time .. When (again!) the answer is you need both: disruptors bringing different paradigms to market, letting organizations pick and choose capabilities based on their needs, making legacy vendors adapt and evolve. Funny to see that rhyme.
  • mojuba 6y ago
    At the end of the day it's dynamic vs. static typing. Both have a place under the Sun.
• singingfish 6y ago
  I stopped reading at "Traditional SQL uses related tables connected by IDs" ... that's what ends up with databases designed with pointless auto-incremented proxy-primary keys.
  • redis_mlc 6y ago
    > I stopped reading at ... Always the sign of a moron. > that's what ends up with databases designed with pointless auto-incremented proxy-primary keys You're actually very incorrect about them being pointless: - databases will assign an implicit numeric id (row id) if you don't (ie. that's what MySQL InnoDB does.) But it may be hidden and unusable if internally-generated, so you just screwed yourself. https://blog.jcole.us/2013/05/02/how-does-innodb-behave-without-a-primary-key/ https://blog.jcole.us/2013/05/02/how-does-innodb-behave-with... - sorting a numeric id is always faster than a long string - most database mgmt. tools require a table numeric primary key to work at all. But cheer up. In one or two decades, you'll be right. Source: DBA.
• f6v 6y ago
  > Because an SQL database uses a schema or structure, this means changes are difficult. Say you’re running a production database full of a million records. Articles like this one perpetuate the myths in the minds of young developers. First off, “millions of records” is nothing this days. More importantly, the scheme ends up living somewhere. If it’s not in your database, you’re likely managing it in the app. There’s no free lunch when it comes to scheme for a typical SaaS.
  • hinkley 6y ago
    > If it’s not in your database, you’re likely managing it in the app “Managed in your app” sounds like a benign state of affairs. Anything that doesn’t have a home ends up smeared across your entire codebase. It isn’t that it’s in the app, it’s that it’s everywhere in the app, meaning changing it becomes a huge investment of energy that people will try to avoid or put off.
    • brabel 6y ago
      > It isn’t that it’s in the app, it’s that it’s everywhere in the app That's only if you don't know how to properly code a data access layer in your application. And if you have many apps using the DB, perhaps the data layer should be in a library.
      • hinkley 6y ago
        I think you need to take a long hard look at the Venn diagram of the user base we are talking about. People who haven’t even learned about Chesterton’s fence have no idea how much they don’t know about robust software.
    • berkes 6y ago
      But if you 'have it in the database' it will still be smeared across your app too. 'Putting stuff in one place', regardless of that place, is hard. Necessary, but hard. And it requires tradeoffs. If you need a 'sorry this username is taken' friendly error, your app needs to handle constraint errors from your DB. Even if only on the translation layer. At which point you'll have it duplicated on multiple layers, add tight coupling between layers, or need to forego that message and e.g. settle with a generic exception instead.
• wnnzl 6y ago
  It’s all about trade-offs. Do you need availability or consistency? https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html https://martin.kleppmann.com/2015/05/11/please-stop-calling-... I would personally never build anything mission critical using NoSQL, sure it’s fast and easy to use, but it might render unreliable in some situations when it’s most important. However 99% of stuff SWE use to build are nowhere close to that level of importance. As long as you know your tool and requirements feel free to use whatever you want, even JSON file on hard drive.
• trhway 6y ago
  There are couple factors: 1. fast hardware, ie. SSD and a lot of RAM allow nowdays to run classic SQL engines without understanding much how to make them perform. All these "millions" or records fit in RAM these days. 2. availability of SQL[-like to various degree] frontends to NoSQL engines.
• Olreich 6y ago
  I find document stores shine when you have known access patterns and can line your data up to meet those patterns. I find relational stores shine when you have unknown access patterns.
• niffydroid 6y ago
  NoSQL, I always understand it as Not Only SQL. At our place we use MongoDB (Main store), SQL, Big Query, Redis, ElasticSearch, then we also store data in S3 that we don't want to query or have the cost of storing in the DB. Pick the right DB for your requirements. Management of them isn't that hard as they're hosted solutions, we've only got to deal with the cost of when a version is EOL, so upgrades or when certain queries will no longer work.
  • snidane 6y ago
    Stonebraker often amusingly describes the NoSQL meaning changing over time as adopters come to realization that SQL is not going away. - NoSQL as No SQL at all - NoSQL as Not Only SQL - NoSQL as Not Yet SQL
• acomjean 6y ago
  I thought the MySQL and Postgres addition of JSON data types took a little of the wind out of nosql sails. That and having a non-uniform api to access data from each type of nosql database.
• plaur782 6y ago
  Ultimately comes down to the right tool for the job. Larger organizations tend to short list a selection of databases to choose from as new applications create new data requirements. These tend to include a NoSQL option, some combination of legacy databases, a data caching or message broker tool, and an open source relational database. Postgres has a lot of momentum as the "new" relational option.
• wdb 6y ago
  I just wish that Cloud SQL on Google Cloud would make it easy to do multi region replication seems impossible with Postgres. I have been using a NoSQL solution lately and each time when you have the need to do joins its a pain as it needs to be done manually and the lack of full text search ain’t fun either which required to use some paid full text search solution. Datastore painful
• BossingAround 6y ago
  Any experience with something like distributed SQL from CockroachDB? The project sounds amazing to be quite frank, but I'd love to hear from someone with first hand experience.
• mettamage 6y ago
  After doing this [1], I never looked back tbh. [1] https://www.sqlteaching.com/ https://www.sqlteaching.com/
• yawnxyz 6y ago
  > First, we have to remember that NoSQL databases are probably great for Amazon and Google but not so great for your side hustle Hold up, what? I hooked up a sign up form with MongoDB Atlas, and it's working brilliantly and it's pretty much free for my side hustle... and it was almost effortless to learn how to implement it... so I don't really agree with this article. Some background: I'm a UX designer, not a dev, and don't have any experience with MySQL (or any free-ish, easy cloud hosted MySQL services, so MDB Atlas was a no-brainer) (recently I've also been experimenting with Fauna and Supabase)
  • walkingolof 6y ago
    Atlas is a fully managed instance. Whats being referenced to here is running your own Cassandra cluster, which is by all accounts, heck of a lot harder than running a Postgres instance.
• breck 6y ago
  SQL is a number of different discrete things including: - A query language - A schema definition language - A storage engine - A server You can mix and match the parts so it works for you.
• Edmond 6y ago
  If only the title was intended as a pun :)
• tgb 6y ago
  The article says that NoSQL has no relations. Is that the case? I would have assumed that, say, you'd make a blog system by making user entries with a list of blog post IDs and then each blog post gets its own entry with its data. If not, are you querying and processing a user's entire blog post history everytime you make an update?
  • dragonwriter 6y ago
    > The article says that NoSQL has no relations. Is that the case? No, not as stated in the article. It is absolutely false that “no matter what format they store data in, these databases don’t support relations between data.” (that's particularly laughable for graph databases.) This sounds like the author knows that “nonrelational” is another term for “NoSQL”, but, as is distressingly common in the field, doesn't know what “relational” means. (It means it doesn't follow the relational model, who is centrally about (though the model has other elements) storing and operating on data in the form of “relations”, a particular logical abstraction (tables, views, etc., are all concrete realizations of this abstraction.)
    • mercer 6y ago
      The distinction between 'SQL' and 'NoSQL' has made less and less sense over time. I can add a JSONB column to my Postgres database and use SQL to query that data, index it, etc. So is that NoSQL or SQL? And while I'm not familiar with MongoDB, I used RethinkDB for a while and while I suppose it would be considered 'NoSQL' it had quite a number of features that I'd associate with a relational DB.
  • jeff-davis 6y ago
    A "relation" in this context roughly means a table that can be manipulated with relational operations (e.g. join). https://en.m.wikipedia.org/wiki/Relation_(database) https://en.m.wikipedia.org/wiki/Relation_(database) EDIT: the sibling comment is right. The article's author seems confused.
• lrossi 6y ago
  When I read the title I thought: this must be yet another closed question. But this is actually posted on their blog. Too bad that you cannot discuss such topics on Stackoverflow. It’s an interesting topic, and it would cause an useful debate.
  • mdaniel 6y ago
    It would be like having a "discussion" inside a column in Excel, since as a Q&A site they have no support for threading, and even the comments cap out at about 6 before the site starts recommending one switch to their separate chat site I wholeheartedly agree with their prohibition on opinions in a Q&A site when HN and Reddit already exist for discussing things