SQL Server Features Implemented Differently in MariaDB

Modern DBMSs implement several advanced features. While an SQL standard exists, the complete feature list is different for every database system. Sometimes different features allow achieving the same purpose, but with a different logic and different limitations. This is something to take into account when planning a migration.

Some features are implemented by different DBMSs, with a similar logic and similar syntax. But there could be important differences that users should be aware of.

This page has a list of SQL Server features that MariaDB implements in a different way, and SQL Server features for which MariaDB has an alternative feature. Minor differences are not taken into account here. The list is not exhaustive.

SQL

• The list of supported is different.

• There are relevant .

• SNAPSHOT isolation level is not supported. Instead, you can use START TRANSACTION WITH CONSISTENT SNAPSHOT to acquire a snapshot at the beginning of the transaction. This is compatible with all isolation levels. See .

Indexes and Performance

• Clustered indexes. In MariaDB, the physical order of rows is delegated to the storage engine. InnoDB uses the primary key as a clustered index.

• Hash indexes. Only some storage engines support HASH indexes.

  • The storage engine has a feature called adaptive hash index, enabled by default. It means that in InnoDB all indexes are created as BTREE

Tables

• Computed columns are called in MariaDB and are created with a different syntax. See also .

• use a different (more standard) syntax on MariaDB. In MariaDB, the history is stored in the same table as current data (but optionally in different partitions). MariaDB supports both and .

• Hidden columns are in MariaDB.

High Availability

• NOT FOR REPLICATION

  • MariaDB supports to exclude some tables or databases from replication

  • It is possible to keep a table empty in a slave (or in the master) by using the .

Security

• The list of is different.

• Security policies. MariaDB allows one to achieve the same results by assigning permissions on views and stored procedures. However, this is not a common practice and it's more complicated than defining security policies. See .

• MariaDB does not support an OUTPUT clause. Instead, we can use and, since , and .

Other Features

• Linked servers. MariaDB supports storage engines to read from, and write to, remote tables. When using the engine, those tables could be in different DBMSs, including SQL Server.

• Job scheduler: MariaDB uses an to schedule events instead.

See Also

_{This page is licensed: CC BY-SA / Gnu FDL}