There are several ways of classifying the database systems available for Linux:
Based on "freeness."
There are commercial packages (sold for a price), and there are free software database systems (that do not cost anything to acquire). This is fairly closely correlated to availability of usable source code, which is another legitimate interpretation of "freeness."
Compatibility/Means of Functioning
xBASE - This is traditionally a "PC" oriented system, of which the first version was known as Vulcan, and ran under CP/M . It was later renamed dBase, and later versions and competitors have followed.
The system model generally involves data structured in a dual fashion similar to ISAM databases with "data" files containing data, and "index" files containing index information. Applications access data directly by reading the files. Newer versions have a network locking system to manage contention for files and/or records if multiple users try to access data simultaneously, but there is still contention inherent in that many programs are accessing the same files simultaneously.
More modern systems use "extent-based" allocation systems to better support the handling of tuples of varying sizes.
SQL - Structured Query Language
Ingres was the progenitor of the modern "query language," with its QUEL query language; a similar query language was then designed that we now know as SQL. SQL is arguably inferior to QUEL, as QUEL had a syntax that is simultaneously simpler and more powerful than that of SQL.
The system model typically involves there being a central database manager "engine" or "process;" application programs do not have direct access to the data. This allows data to be relatively protected from corruption/misuse by rogue processes.
It is common for the database manager to use a variety of the "nonrelational" database tools to implement tables; commonly used in older systems are ISAM access methods. The use of nonsequential hashed methods similar to DBM are commonly available with more modern database systems, although since the properties of approximate-match searches with hash tables are extremely poor, they are not as popular.
SQL is not without its problems: There are a number of other problems that injure the notion of calling it "relational".
It doesn't provide a perfectly regular set of "syntax".
It suffers from common bits of mathematical illiteracy such as lying about the nature of data types. The pointed example: REAL types are absolutely not like the domain of real numbers you find in mathematics. The REAL type in SQL is, instead, a rational number representation with variable precision.
SQL tables are not necessarily relations.
SQL does not support relational domains, although CREATE DOMAIN, supported in the more recent standard, is moving in the right direction...
Typical implementations associate some sort of position to columns, which violates the definition of a relation.
SQL permits duplicate records.
SQL result sets can contain duplicates and nulls, notably when processing outer joins, thus violating closure.
Everyone uses UNION ALL instead of UNION, because the latter is so much slower since it is required to eliminate duplicates.
Views are not relations.
No SQL system provides updatable views, and the lack of a sound theoretical basis for handling them is a problem.
NULLs are a terrible problem.
They look like they're not values, but sometimes are. The standard's handling of them is rife with illogic and inconsistency.
The essay What is the deal with NULLs? demonstrates ways in which standard handling of NULL is illogical.
I believe the above shows, beyond a reasonable doubt, that NULL semantics are unintuitive, and if viewed according to most of the "standard explanations," highly inconsistent. This may seem minor; that is, if you're writing SQL you can overcome these things with training. But it is not minor, because NULL semantics are designed to make you think you understand them, and think that the semantics are intuitive, and think that it's part of some ingenious consistent system for managing missing information. But none of those things are true.
The Third Manifesto responds to this by proposing a more strongly " relational" database language, supporting the notion of expressing more assertions and constraints about the nature of the data within the database engine. This also somewhat parallels the way Prolog allows expressing both "facts" and " rules" as to how the facts relate.