[055static]

So the language implies something about the functionality of the database. That seems obvious enough.

But does it necessaruly tell you anything about the underlying structure and the performance of a database?

If we drop that acronym, "SQL", and still provide a database that handles relational queries (but perhaps uses a different but equally capable language), does that matter? If yes, how much? And why?

[andrewcooke]

sql is actually quite close to a natural way of expressing relations. there's a book called "sql and relational theory" by someone called chris date that goes into a lot of detail about this ("relations" is a technical term with a pretty solid mathematical basis). so you could change the syntax, but the basic ideas wouldn't change that much, assuming it was still a relational database.

the value of the different database implementations comes from how efficiently they can implement the relational model, and what optimizations they have to support particular use cases, or extensions to make supporting and maintaining them more practical. those optimizations/extensions also lead to some of the differences between what sql might be if it were "purely relational" and what is is in practice.

so dropping sql and using a different language would be more a nuisance than anything. what is important is whether the database is relational or not. and databases that are not relational have been tried - they are (misleadingly!) called "nosql databases" (they should be more accurately called "non-relational databases", of course, given the above).

[EwanToo]

There's plenty of database systems that either don't support SQL at all, or support it with a range of other languages.

One of SQL's remaining powers over most other options is the ability of non-expert users to construct their own ad-hoc reports. This is a big part of why Hadoop has Hive, which incorporates a very SQL-like language, and most other "big data" tools have something similar.