{{ !articles[0].partner.isSponsoringArticle ? "Platinum" : "Portal" }} Partner

MoreSQL (formerly NewSQL): A Serious Competitor for NoSQL

Back in November, Alex Tatiyants made some waves with his article, "NoSQL No More: Let's double down with MoreSQL," when he made the the following tongue-in-cheek call to arms . . .

Today, I am calling on developers everywhere to join a new movement dedicated to bringing back the golden era of relational databases: MoreSQL --Alex Tatiyant

He even made the sweet MoreSQL logo to the right.
And while the post was sarcastic in tone, a response by William Edwards sheds some light on how the MoreSQL/NewSQL movement might be worth taking seriously.  Edwards contends that the movement to NoSQL came when we realized that joins in database queries can be bad for database performance.  He then suggests that once Google and Amazon started to react to the problems of scale, developers tried to abandon SQL . . .

So the rest of us set out to do away with joins, throw out SQL too and head down a new rabbit-hole of non-ORM object-something-mappings.  Really the whole ORM vs not-quite-ORM-but-still-a-restrictive-set-of-cursor-based-interface thing is not making scaling easier for anyone - its all about sufficiently smart compilers and just pushing the impedance mismatch between coder and data-store around.  --William Edwards

Now, the question for database developers becomes: What's next?  According to Edwards, we need to "look to Google to lead the web-scale way."  Google has already been making headway with their own MoreSQL implementation, detailed in their recently published paper titled, "Tenzing - A SQL Implementation On The MapReduce Framework."  Edwards also points to fractal tree databases as a potential area for leaps and bounds in performance.  If you're curious, check out Tokutek, a company that claims to improve database operations by 20X-80X.  Pretty impressive.  

Trend setters and followers aside, the important thing here is making database performance faster, and Edwards isn't about to admit that someone other than the independent compiler is going to "cut out all the abstractions and layers" between him and the database . . .

 . . .you have to write your own prepared query statements yourself, because you know the architecture of the other end.  You are the only compiler sufficiently smart to work all this out. --William Edwards
{{ tag }}, {{tag}},

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}
{{ parent.authors[0].realName || parent.author}}

{{ parent.authors[0].tagline || parent.tagline }}

{{ parent.views }} ViewsClicks