Application Migration

In many situations there are already applications running for quite some time and the question arises if it is worth to switch over to MonetDB/e. In those cases, the effort required should be kept to a minimum. Note that MonetDB/e provides a wealth of SQL features derived from Monetdb directly, i.e. enriched base types, controlled parallelism, persistent stored modules, UDFs,… which are not necessarily available in the systems mentioned below. Using such features may improve the performance of you program, but also could hinder a reversion from a MonetDB/e application into your hitherto favored system.

Porting SQLite3 programs

A plethora of programs are written in SQLite 3 and its website contains an extensive account on the particulars.

Migration starts with replacing all occurrences of the sqlite3 with monetdbe in the Python program.

The following functionality is not supported by MonetDB/e or contains syntax/semantic differences.

  • SQLite is based on manifest typing, MonetDB/e on rigid types.

  • SQLite allows current access to the same local database using file-based locking?

  • No cross platform data exchange format (big- little- endians)

  • Thread safety no specific control.

  • Copy statement delimiters may be different.

  • INTEGER PRIMARY KEY should be mapped to the SERIAL type in MonetDB/e.

  • VACUUM is not supported. Garbage collection is implicit.

  • EXPLAIN is based on the MonetDB abstract machine.

  • PRAGMAs are not recognized.

  • ON CONFLICT not supported.

  • REPLACE not supported

  • ATTACH and DETACH replaced by connect().

  • Collating Sequences.

  • JDBC connector.

  • FTS5 not supported.

  • Rtree not supported.

Porting DuckDB programs

DuckDB is an embedded analytical data management system researched at the Database Architectures group of CWI. Migration starts with replacing all occurrences of ‘duckdb’ with ‘monetdbe’.

The following functionality is not supported by MonetDB/e or contains syntax/semantic differences.

Reporting issues

We highly appreciate user feed back for migrations undertaken in the MonetDB/e issue tracker on GitHub or stackoverflow. Both as a warning and best practices for those who follow, but also to assess the need for features hitherto not available in MonetDB/e

We welcome migration advice for other (embedded) database systems. Features needed can be left behind in the issue tracker.