Take the 2-minute tour ×

I occasionally hear things about how SQL sucks and it's not a good language, but I never really hear much about alternatives to it. So, are other good languages that serve the same purpose (database access) and what makes them better than SQL? Are there any good databases that use this alternative language?

EDIT: I'm familiar with SQL and use it all the time. I don't have a problem with it, I'm just interested in any alternatives that might exist, and why people like them better.

I'm also not looking for alternative kinds of databases (the NoSQL movement), just different ways of accessing databases.

share|improve this question
SQL sucks? Any references? –  Murali VP Mar 23 '10 at 2:41
You're not saying it sucks compared to XML are you? –  Bratch Mar 23 '10 at 2:44
Whether SQL actually sucks or not is something I'm interested in. Here's an example though: en.wikipedia.org/wiki/The_Third_Manifesto I guess "sucks" might be the wrong word.. –  Brendan Long Mar 23 '10 at 2:44
To clarify: I have no problem with SQL. I just like learning about other ideas in case there is something better. –  Brendan Long Mar 23 '10 at 2:45
If it has to be a query language, and has to be for an RDBMS, then check out Quel: en.wikipedia.org/wiki/QUEL_query_languages -- it's also what Postgres used before 1995, when it also changed its name to the exceptionally silly "PostgreSQL". –  Ken Mar 23 '10 at 3:20
show 3 more comments

closed as not constructive by Robert Harvey Dec 31 '12 at 16:08


16 Answers

up vote 14 down vote accepted

I certainly agree that SQL's syntax is difficult to work with, both from the standpoint of automatically generating it, and from the standpoint of parsing it, and it's not the style of language we would write today if we were designing SQL for the demands we place on it today. I don't think we'd find so many varied keywords if we designed the language today, I suspect join syntax would be different, functions like GROUP_CONCAT would have more regular syntax rather than sticking more keywords in the middle of the parentheses to control its behavior... create your own laundry list of inconsistencies and redundancies in SQL that you'd like/expect to see smoothed out if we redesigned the language today.

There aren't any alternatives to SQL for speaking to relational databases (i.e. SQL as a protocol), but there are many alternatives to writing SQL in your applications. These alternatives have been implemented in the form of frontends for working with relational databases. Some examples of a frontend include:

I think that the underlying theme today is that rather than replace SQL with one new query language, we are instead creating language-specific frontends to hide the SQL in our regular every-day programming languages, and treating SQL as the protocol for talking to relational databases.

share|improve this answer
Interesting. That makes sense though. –  Brendan Long Mar 23 '10 at 3:47
add comment

Take a look at this list.

I haven't heard of any of them, except for Hibernate Query Language. The advantage of Hibernate is that objects map very easily (nearly automatically) to the relational database, and the developer doesn't have to spend much time doing database design. Check out the Hibernate website for more info. I'm sure others will chime in with other interesting query languages...

share|improve this answer
Definitely the sort of thing I was looking for. –  Brendan Long Mar 23 '10 at 2:52
That list has a very wierd collection of languages on it. I don't think XQuery belongs, and I don't know enough about D to know why it belongs. –  Ken Bloom Mar 23 '10 at 3:26
@Ken Bloom apparently there's a query language called D, and a seperate C-like language called D. The first one I thought of was the c-like language.. –  Brendan Long Mar 23 '10 at 3:40
I definitely spoke too fast about D. When I saw the name, I was thinking Digital Mars' D -- I see that the D data language is something else entirely. –  Ken Bloom Mar 23 '10 at 3:45
c2.com/cgi/wiki?QueryLanguageComparison is also worthwhile –  Ken Bloom Mar 23 '10 at 3:58
add comment

Perhaps you're thinking of the criticism C. Date and his friends have uttered against existing relational databases and SQL; they say the systems and language aren't 100% relational, and should be. I don't really see any real problem here; as far as I can see you can have a 100% relational system just by disciplining the way in which you use SQL.

What I personally keep running into is the lack of expressive power SQL inherits from its theoretical basis, relational algebra. One issue is the lack of support for the use of domain ordering, which you run into when you work with data marked by dates, timestamps, etcetera. I once tried to do a reporting application entirely in plain SQL on a database full of timestamps and it just wasn't feasible. Another is the lack of support for path traversal: most of my data look like directed graphs that I need to traverse paths in, and SQL can't do it. (It lacks "transitive closure". SQL-1999 can do it with "recursive subqueries" but I haven't seen them in actual use yet. There are also various hacks to make SQL cope but they're ugly.) These problems are also discussed by some of Date's writings, by the way.

Recently I was pointed at .QL which appears to address the transitive closure issue nicely, but I don't know whether it can resolve the issue with ordered domains.

share|improve this answer
There are some faults that prevent "100% relational systems" even with "disciplining the way in which you use SQL", because SQL, is not truly relational. Example: SELECT Sum(foo) BAR Blah WHERE 1=0. SQL returns null, 100% relational demands a zero. carfield.com.hk/document/misc/SQL_Problems.pdf –  McKay Oct 28 '10 at 19:53
Also, do you write "DISTINCT" after every select? –  McKay Oct 28 '10 at 19:59
Yes, I'd avoid NULL completely (so there needs to be special-casing for empty results) and either write DISTINCT everywhere or at least wherever I need to use COUNT. –  reinierpost Oct 29 '10 at 8:12
add comment

Take a look at LINQ to SQL...

Tried it out a couple months ago and never looked back....

share|improve this answer
I can second that! –  Quagmire Mar 23 '10 at 22:36
Linq is wonderful, but only if you are developing on .NET :) –  Justin Ethier Mar 24 '10 at 18:44
add comment

The general movement these days is NoSQL; generally these technologies are:

Personally I think there is nothing wrong with SQL as long as it fits your needs. SQL is expressive and great for working with structured data.

share|improve this answer
+1 for document-oriented databases. As datasets grow in size, relational models can become really slow... –  Mike Cialowicz Mar 23 '10 at 2:47
What you mention are not alternatives to SQL, they are not even languages. Initiatives such as Apache Pig and Apache Hive are more like it. –  reinierpost May 16 '13 at 8:47
add comment

"I occasionally hear things about how SQL sucks and it's not a good language"

SQL is over thirty years old. Insights about "which features make something a 'good' language and which ones make it a 'bad' one" have evolved more rapidly than SQL itself.

Also, SQL is not a language that conforms to current standards of "what it takes to be relational", so, SQL just isn't a relational language to boot.

"but I never really hear much about alternatives to it."

I invite you to ponder the possibility that you are trying to hear only in the wrong places (that is, the commercial DBMS industry exclusively).


Date&Darwen describe the features that a modern data manipulation language must conform to in their "Third Manifesto", the most recent version of which is laid down in their book "Databases, Types & the Relational Model".

"Are there any good databases that use this alternative language?"

If by "good", you mean something like "industrial-strength", then no. The closest thing available would probably be Dataphor.

The Rel project offers an implementation for the Tutorial D language defined in "Databases, Types & The Relational Model", but the current prime goal of Rel is to be educational in nature.

My SIRA_PRISE project offers an implementation for "truly relational" data management, but I hesitate to also label it "an implementation of a language".

And of course, you might also look into some non-relational stuff, as some have proposed, but I personally dismiss non-relational data management as multiple decades of technological regression. Not worth considering, that is.

Oh, and by the way, a software system that is used to manage databases is not "a database", but "a DataBase Management System", "DBMS" for short. Just like a photograph is not the same thing as a camera, and if you are discussing cameras, and you want to avoid confusion, then you should be using the proper word "cameras" instead of "photograph".

share|improve this answer
Non-relational databases seem to have some use (some applications get better performance out of less structured data), so I wouldn't call it a regression. Nice answer though. –  Brendan Long Mar 23 '10 at 22:43
It is an age-old frustration of all relational people that "performance" seems to be perceived as a characteristic of the model. That perception is flawed, period. Performance is a characteristic of the implementations of the model. That any currently existing implementation of the RM indeed seems to often raise performance problems, is a combination of multiple factors : (a) implementing the RM in full is just plain extremely difficult, (b) DBMS vendors not pushing hard enough for new implementation progress, and (c) users lacking sufficient understanding of underlying algorithmics. –  Erwin Smout Mar 23 '10 at 22:59
@Erwin But if we find that a particular model is inherently difficult to implement efficiently, then surely it is fair to say that there is a problem with that model from an efficiency point of view. –  Jay Sep 4 '12 at 14:30
add comment

SQL works fine for the domain for which it was designed — interrelated tables of data. This is generally found in traditional business data processing. SQL doesn't work that well when trying to persist a complex network of objects.

If your needs are to store and process relatively traditional data, use some SQL-based DBMS.

In response to your edit:

If you're looking for alternatives to the SQL DML for retrieving data from relational data stores, I've never heard of any serious alternative to SQL.

The knocks SQL gets are not, I think, so much against the language as opposed to the underlying data storage principles on which the language is based. People often confuse the language SQL with the relational data model on which RDBMSes are built.

share|improve this answer
Yeah I realized after writing this that everyone things that SQL and relational databases are the same thing.. –  Brendan Long Mar 23 '10 at 3:19
add comment

SQL is de-facto.

Frameworks that try to shield developers from it have eventually created their own specific language (Hibernate HQL comes to mind).

SQL solves a problem fairly well. It is no more difficult to learn than a high level programming language. If you already know a functional language then it is a breeze to grasp SQL.

Considering the leading database vendors providing state of the art databases (Oracle and SQL Server) support SQL and have invested years into optimization engines, etc. and all leading data modelling software and change management software deals in SQL, I'd say it is the safest bet.

Also, there is more to a database than just queries. There is scalability, backup and recovery, data mining. The big vendors support a lot of things that even the new "cache" engines don't even consider.

share|improve this answer
LINQ isn't a language designed to shield developers from SQL, it's a query syntax used to interrogate collections, which can be extended to support different collection sources. SQL databases just happen to be one of those sources. –  Khanzor Mar 23 '10 at 2:45
Good point, LINQ is not a valid example. Edited. –  mrjoltcola Mar 23 '10 at 3:08
add comment

Back in the 1980's, ObjectStore provided transparent object access. It was kind of like an RDBMS plus an ORM, except without all those extra leaky abstraction layers: it stored objects directly in the database.

So this alternative was really "no language at all", or perhaps "the language you're already using". You'd write C++ code and create or traverse objects as if they were native objects, and the database took care of everything as needed. Kind of like ActiveRecord but it actually worked as well as the ActiveRecord marketing blitzes claim. :-)

(Of course, it didn't have Oracle's marketing muscle, and it didn't have MySQL's zero-cost, so everybody ignored it. And now we try to replicate that with RDBMSs and ORMs, and some people try to argue that tables actually make sense for storing objects, and that writing giant XML file to tell your computer how to map objects to tables is somehow a reasonable solution.)

share|improve this answer
That's pretty cool. –  Brendan Long Mar 23 '10 at 3:22
The downside to this sort of having your query language be "the language you're already using", at least in those days, is that there wasn't much room for the database to optimize access patterns. One thing I like about SQL is that it's declarative, and the database does the nitty-gritty work to figure out how to preform the query best. No other language today comes close to providing that much intelligence about optimization. I just think we'd normalize the keywords a bit more, and simplify the syntax if we rewrote it today. –  Ken Bloom Mar 23 '10 at 3:23
Counterpoint: Query optimizers are, in the grand scheme of things, pretty dumb. Look how many "help me optimize my query" questions there are here on SO. To write an efficient query, you have to understand what the query optimizer is going to do. I've already got a profiler for my programming environment -- and a debugger, for that matter -- and they're miles better than any EXPLAIN I've ever seen. I don't know how good ObjectStore is at this, but a homogeneous software stack can be awesome. –  Ken Mar 23 '10 at 4:21
In 2011, you can just download the free version of Gemstone and program in Smalltalk. The only thing to think about is how to migrate instances of one class version to another (the simple cases it handles automatically) –  Stephan Eggermont Apr 19 '11 at 21:45
add comment

I think you might be interested in looking at Dataphor, which is an open-source relational development environment with its own database server (which speaks D), and the ability to derive user interfaces from its query language.

Also, it appears Ingres still supports QUEL, and it's open source.

share|improve this answer
Technically, the language the dataphor server speaks is D4, D (or tutorial D...) is a slightly different language. –  McKay Oct 28 '10 at 19:56
add comment

There are many implementations of SQL (SQL Server, mysql, Oracle, etc.), but there is no other language that serves the same purpose in the sense of being a general purpose language designed for relational data storage and retrieval.

There are object databases such as db4o, and there are similar so-called noSQL databases that refer to just about any data storage mechanism that doesn't rely on SQL, but most commonly open-source products like Cassandra based loosely on Google's Bigtable concept.

There are also a number of special-purpose database products like CDF, but you probably don't need to worry about those - if you need one, you'll know.

None of these are equivalent to SQL.

That doesn't mean they're "better" or "worse" - they're just not the same. Dennis Forbes wrote a great post recently breaking down a number of the strange claims surfacing against SQL. He maintains (and I agree) that these complaints originate largely from people and shops who have either picked the wrong tool for the job in the first place, or aren't using their SQL DBMS properly (I'm not even surprised anymore when I see another SQL database where every column is a varchar(50) and there's not a single index or key, anywhere).

If you are implementing yet another social networking site and aren't too concerned with ACID principles, by all means start looking into products such as db4o. If you are developing a mission-critical business system, however, I highly highly recommend that you think twice before joining the "SQL sucks" chorus. Do the research first, find out what features the various products can and cannot support.

Edit - I was busy writing my answer and didn't get the question update from a few minutes. Having said that, SQL is essentially inseparable from the DBMS itself. If you run a SQL database product, then you access it with SQL, period.

Perhaps you are looking for abstractions over the syntax; Linq to SQL, Entity Framework, Hibernate/NHibernate, SubSonic, and a host of other ORM tools all provide their own SQL-like syntax that is not quite SQL. All of these "compile down" to SQL. If you run SQL Server, then you can also write CLR Functions/Procedures/Triggers, which allows you to write code in any .NET language that will run inside the database; however, this isn't really a substitute for SQL, more of an extension to it.

I'm not aware of any full "language" that you can layer on top of a SQL database; short of switching to a different database product, you're eventually going to see SQL on the pipe.

share|improve this answer
I think you're confusing relational databases with SQL databases. There's no particular reason a relational database has to use SQL (except everyone else uses it). And yes, I realize most database products only use SQL. –  Brendan Long Mar 23 '10 at 3:09
@Brendan Long: That's correct, a relational database does not have to use SQL. However, that is what relational databases do use. Other non-SQL products in existence today are not relational databases. –  Aaronaught Mar 23 '10 at 3:10
What about D and Quel? They don't seem very popular, but they exist (and they're used for relational databases). –  Brendan Long Mar 23 '10 at 4:14
@Brendan Long: Quel, as far as I know, has been superseded by SQL. First time I've heard of D, and from the wiki article I looked at it appears that it's not really a language per se but rather a defined set of features that a DB language should have. While there might be some very obscure implementations, I don't think this substantially changes anything above. Also, I think you should realize that when people say "SQL Sucks", they are not referring to the SQL grammar, they are (rightly or wrongly) referring to SQL-based relational databases. –  Aaronaught Mar 23 '10 at 4:23
add comment

Direct answer: I don't think there's any serious contender out there. DBase and its imitators (Foxpro, Codebase etc) was a contender for a while, but I think they basically lost the database query language war. There have been many other database products that had their own query language, like Progress and Paradox and several others I've used whose names I don't remember and surely many more that I never heard of. But I don't think any other contender even came close to getting a non-trivial share of the market.

As simple proof that there is a difference between a database format and a query language, the last version of DBase I used -- many years ago now -- offerred both the "traditional" DBase query language and SQL, both of which could be used to access the same data.

Side ramble: I wouldn't say that SQL sucks, but it has many flaws. With the benefit of the years of experience and hindsight we now have, I'm sure one could design a better query language. But creating a better query language, and convincing people to use it, are two very different things. Would it be enough better to convince people that it was worth the trouble of learning. People have invested many years of their lives learning to use SQL effectively. Even if your new language is easier to use, there would surely be a learning curve. And how would you migrate your existing systems from SQL to the new language? Etc. It can be done, of course, just like C++, C#, and Java have largely overthrown COBOL and FORTRAN. But it takes a combination of technical superiority and good marketing to pull it off.

Still, I get a chuckle out of people who rush forward to defend SQL anytime someone criticizes it, who insist that any problem you have with SQL must be your own ineptitude in using it and not any fault of SQL, that you must just not have reached the higher plane of thingking necessary to comprehend its perfection, etc. Calm down, take a deep breath: We are insulting a computer language, not your mother.

share|improve this answer
@Jay: one possible replacement to SQL could be no database specific language at all, use your usual OO programming language for data persistency. See my answer about Object-databases and ORM. I wouldn't say ORMs are not getting some market share nowaday. –  kriss Mar 23 '10 at 23:28
Kriss: I was thinking that ORMs aren't a "query language" but rather something that sits on top of a query language. I suppose if that is what you use to communicate with the database, it could be considered the query language, and maybe I'm just being pedantic. Like, I recall many years ago reading that COBOL and C aren't REALLY computer languages, that only assemblers are real computer languages. COBOL and C are just things that get translated into a computer language. The argument seemed then and now to be simply silly.) So: Okay, I'll buy that. –  Jay Mar 24 '10 at 13:27
add comment

Relational Databases are not the only kind of databases around. I should say a word about Object-Databases as I havn't seen it in responses from others. I had some experience with the Zope python framework that use ZODB for objects persistency instead of RDBMS (well, it's theoretically possible to replace ZODB by another database within zope but the last time I checked I didn't succeed to have it working, so can't be positive about that).

The ZODB mindset is really different, more like object programming that would happen to be persistent.

ORM can be seen as a kind of language

In a way I believe the Object-database model is what ORM are about : accessing persistent data through your usual object model. It's a kind of language and it's gaining some market share, but for now we don't see it as a language but as an abstraction layer. However I believe it would be much more efficient to use an ORM over an Object-database than over SQL (in other words performance of ORMs I happened to use using some SQL database as base layers sucked).

share|improve this answer
add comment

Within the .NET world, while it still has a SQL-esque feel to it, LINQ-to-SQL will allow you to have a good mix of SQL and in-memory .NET processing of your data. It also simplifies a lot of the lower-level data plumbing that nobody really wants to do.

If you want to see a database type of a completely different mindset, take a look at CouchDB. "Better" is obviously a relative requirement and this sort of non-relation database is "Better" but only in certain scenarios.

share|improve this answer
add comment

SQL the language is very powerful, and relational database management systems have been and still are a huge success. But there is a class of application that requires very high scalability and availability, but not necessarily a high degree of data consistency (eventual consistency is what matters). A variety of systems get better performance and scaling than an RDBMS by relaxing the need for full ACID compliant transactions. These have been named "NoSQL", but as others point out, this is a misnomer: that perhaps they should be called NoACID databases.

Michael Stonebraker covers this in The "NoSQL" Discussion has Nothing to Do With SQL.

share|improve this answer
So are NoACID "databases" an alternative to SQL as a database access language? No, they are not. –  reinierpost Apr 20 '10 at 15:39
While SQL is powerful, Relational Algebra is more powerful. –  McKay Oct 28 '10 at 19:57
@reineirpost: Agreed. You could use SQL to query a NoACID database. You could query text files instead of relations too (some of the ancient Unix command line tools correspond to operations in relational algebra. –  Jim Ferrans Oct 28 '10 at 20:55
@McKay: Is there a commercial RDBMS that supports a relational algebra syntax? That would be cool. –  Jim Ferrans Oct 28 '10 at 22:02
Other people in this thread have mentioned stuff like Dataphor and aiming to follow Relational Algebra better. –  McKay Nov 1 '10 at 14:41
add comment

Problems with SQL have motivated me to cook up a draft query language called SMEQL over at the Portland Pattern Repository wiki. Comments Welcome. It borrows ideas from functional programming and IBM's experimental Business System 12 language. (I originally called it TQL, but found later that name was taken.)

share|improve this answer
add comment
