if i understand what you're asking then i think you'd call it an implementation. both mysql and postgresql are database implementations that can be queried using the sql language. however, both also extend the language (as defined by ansi standard) in various ways.
I'm curious where the most perceived "value" is. For example, is it in the internal structures of the database? Is it in the query language? Is it in the fact that everything is packaged together as a "system"?
I have seen a database that uses an SQL-like language but it is not a RDB. It's said to be much faster than Oracle, but it certainly doesn't need the SQL syntax to work. Needless to say, the speed doesn't come from the SQL syntax. :)
It made me wonder about decoupling the language from the interpreter. Without the SQL characteristic, would anyone be attracted to the MySQL, PostgresSQL, ..., WhizBangSQL systems?
what postgresql, mysql etc. provide is a relational database, i.e. a way to store table-structured data with consistency and safety guarantees and efficiently perform operations to retrieve and update rows from it. sql is simply the standard language in which relational queries are expressed.
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?
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).
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.