Introduction

To delete all rows from a SQLite table on Android, the normal solution is either db.delete(table, null, null) or db.execSQL("DELETE FROM table"). Both remove every row because there is no WHERE clause. The practical difference is mostly API style. In Android code, delete(...) is usually clearer and safer because it avoids manually composing SQL strings.

The Straightforward Android API

If you already have a writable database from SQLiteOpenHelper, this is the most idiomatic form:

val db = dbHelper.writableDatabase
val rowsDeleted = db.delete("users", null, null)
println("Deleted $rowsDeleted rows")

Passing null for the selection and selection arguments means "delete every row in the table."

This is usually the best answer for app code because it is explicit and easy to read.

Equivalent Raw SQL

You can do the same thing with raw SQL:

val db = dbHelper.writableDatabase
db.execSQL("DELETE FROM users")

This works too, but it gives you no direct deleted-row count and is less structured than the delete(...) call.

Use raw SQL when you truly need it, not by default.

Full Example With SQLiteOpenHelper

1import android.content.Context
2import android.database.sqlite.SQLiteDatabase
3import android.database.sqlite.SQLiteOpenHelper
4
5class AppDatabase(context: Context) : SQLiteOpenHelper(context, "app.db", null, 1) {
6    override fun onCreate(db: SQLiteDatabase) {
7        db.execSQL("""
8            CREATE TABLE users (
9                id INTEGER PRIMARY KEY AUTOINCREMENT,
10                name TEXT NOT NULL
11            )
12        """.trimIndent())
13    }
14
15    override fun onUpgrade(db: SQLiteDatabase, oldVersion: Int, newVersion: Int) = Unit
16
17    fun clearUsers(): Int {
18        val db = writableDatabase
19        return db.delete("users", null, null)
20    }
21}

Now the rest of the app can call clearUsers() instead of scattering delete logic around the codebase.

Use A Transaction For Multi-Step Cleanup

If table cleanup is part of a larger reset flow, wrap it in a transaction.

1val db = dbHelper.writableDatabase
2db.beginTransaction()
3try {
4    db.delete("users", null, null)
5    db.delete("sessions", null, null)
6    db.setTransactionSuccessful()
7} finally {
8    db.endTransaction()
9}

This matters when multiple tables must be cleared together consistently.

DELETE Is Not TRUNCATE

A common point of confusion: SQLite does not support TRUNCATE TABLE the way some other databases do. Use DELETE FROM tableName or the Android delete(...) wrapper.

If you need to reset an autoincrement sequence too, that is a separate concern. Deleting rows does not automatically guarantee the exact future ID behavior some developers expect.

Large Deletes And File Size

Deleting rows removes the data logically, but it does not necessarily shrink the database file immediately. If reclaiming disk space matters after a large cleanup, you may need VACUUM.

val db = dbHelper.writableDatabase
db.execSQL("VACUUM")

Do not run VACUUM casually in latency-sensitive paths. It can be expensive.

When Dropping And Recreating The Table Makes Sense

If your goal is a full reset during development or local cache rebuild, another option is dropping and recreating the table. That is heavier and more destructive than deleting rows, so it is usually best reserved for schema migration or complete local state reset logic.

If the table structure should remain the same and only the rows should go away, delete(...) is the right tool.

Common Pitfalls

• Looking for TRUNCATE TABLE in SQLite even though SQLite uses DELETE instead.
• Building raw SQL strings unnecessarily when db.delete(...) already expresses the operation clearly.
• Forgetting transactions when clearing multiple related tables as one logical reset.
• Assuming the database file will shrink immediately after deleting rows.
• Confusing row deletion with resetting autoincrement behavior.

Summary

• On Android with SQLite, delete all rows with db.delete("table", null, null).
• 'db.execSQL("DELETE FROM table") is equivalent but usually less convenient.'
• SQLite does not support TRUNCATE TABLE.
• Use transactions when clearing multiple tables together.
• If reclaiming disk space matters after large deletions, consider VACUUM separately.