When creating temporary tables within Falcon, the tables are automatically created in the FALCON_TEMPORARY tablespace. If you specify an alternate tablespace to the CREATE TABLE statement then a warning will be issued.

Falcon uses sequences when creating values in tables with an AUTO_INCREMENT column. Once a sequence has been created, the auto-increment value has already been allocated, even if the transaction is rolled back. This means that the informaiton report by SHOW TABLE STATUS about the next auto-increment value in the table is correct, but may be different from what you expect compared to the behavior of InnoDB tables.

During a transaction, the count of the number of records within a Falcon table shown by SHOW TABLE STATUS reflects the number of rows in the table before the transaction was started. Because of this, the value is consistent even if the user later roll back the transaction. The information is only updated when the records are finally committed to the table.

If the table is empty, then the row count shown by SHOW TABLE STATUS will be 2. During a transaction where new rows written into a table with an AUTO_INCREMENT column, the row count will continue to register the lower value, even though the next_increment value will show the correct value and show that rows have been inserted into the table. This is because Falcon uses sequences that allocate the increment value, and increment values are never re-used, even if the transactions are rolled back.

This behaviour is different to both MyISAM and InnoDB behavior when comparing the output of SHOW TABLE STATUS and auto incremented values.

Starting with MySQL 6.0.4, Falcon will reject tables where an AUTO_INCREMENT column has been declared as part of a multi-column index but is not the first column in the index. This mirrors the behaviour of InnoDB, but is incompatible with the support provided in MyISAM for such tables. For more information on this behavior, see Section 3.6.9, “Using AUTO_INCREMENT”.

Starting with MySQL 6.0.6, Falcon provides Page checksum protection.

Falcon does not currently support live downgrades due to the changes in the structure of the serial log and tablespace structures. For example, you cannot downgrade from MySQL 6.0.5 to MySQL 6.0.4. If you need to downgrade your current installation to an earlier version, you must dump your database using mysqldump, downgrade, and then re-import the dumped database.

Falcon behaves as if the lower_case_table_names option has been enabled irrespective of the current platform.

There is a limit of 2³² (4.29 billion) rows for a single table. By using multiple tables within the same tablespace you can have more than this number of records. In future releases this limit will be removed.

Each tablespace has a limit of 2³² pages within a single tablespace. Through a combination of the page size and the maximum number of pages in a tablespace, there is a limit of 140,737,488,355,328 bytes (128 TB) to a single tablespace.

Online backup is not supported, but support is planned in a future release.

Foreign key support is currently not available.

Falcon does not support statement-based logging and replication. If you have set --binlog-format=STATEMENT, or --binlog-format=MIXED then logging for Falcon tables will automatically use ROW based logging, irrespective of those settings.

Although the maximum available storage within a tablespace is 128TB, the true number of records and quantity of data that you can store is dependent on a number of factors:

Because of the complex relationship between the storage, indexing and compression facilities it is impossible to predict or calculate the disk storage space required for a specific data set.