Like most relational databases, RethinkDB has several different commands to delete records from a database.
To test the behavior, I made several copies of an existing table I had, which took ~1 minute per:
r.db('performance')
.tableCreate('query_timings2')
r.db('performance')
.table('query_timings2')
.insert(r.db('performance')
.table('query_timings'))
Currently, the SQL to ReQL comparision guide lists this as the equivalent of “truncate”:
r.db('performance')
.table('query_timings')
.delete()
In my database, this took about the same amount of time as creating the original table. I believe this runs in a transaction, as when I abort the query the number of rows remains the same.
In many relational databases, “truncate” has a specific meaning; in Oracle it deletes the underlying filesystem from disk immediately and outside a transaction. In Postgres it runs within a transaction but skips any effort required to verify rows, which appears to match what an unqualified delete does in RethinkDB.
If you would like to replicate the Oracle behavior, dropping and re-creating a table seems to be much faster (I only know this experimentally, so I don’t know if this runs outside a transaction)
r.db('performance')
.tableDrop('query_timings') -- 45 ms
r.db('performance')
.tableCreate('query_timings')
RethinkDB has two other neat feature that I’ve not seen in other databases; the option to do a “hard” vs “soft” delete, and whether to return the deleted rows:
r.db('performance')
.table('query_timings2')
.delete({durability="soft", returnChanges=false})
In my test, the “soft” delete took about half the time of the “hard” delete (basically it is not waiting for the OS to confirm changes were written to disk).