Tutor LMS Database Tables: Every Custom Table and What It Stores

Tutor LMS 4.1.3 (the free plugin) creates 20 custom database tables: 15 in its activation routine, two in its 3.8.0 upgrade step and three for the GDPR consent feature added in 4.0.0. The Tutor LMS database tables hold quiz attempts and answers, quiz questions, the native e-commerce data (orders, order items, coupons, carts, customers), instructor earnings and withdrawals, a scheduler and consent records. Courses, topics, lessons, quizzes and enrolments are not in custom tables: they are posts in wp_posts, and lesson and course completion live in user meta and comments.

Tutor LMS Pro adds up to 14 more tables when you switch on specific add-ons, so a Pro site can have 34. This reference lists every table, what it stores, which code creates it and the details that matter for reporting, backups and migrations. It stays at architecture depth; for step-by-step Tutor LMS help, see our sister site Tutor LMS Expert.

Checked against the Tutor LMS 4.1.3 and Tutor LMS Pro 4.1.3 source (classes/Tutor.php, classes/Upgrader.php, GDPR/DB/ and the Pro add-on Database classes), as of October 2026. Table names use the default wp_ prefix; your site uses $wpdb->prefix.

The 20 core Tutor LMS tables at a glance

How Tutor LMS creates and upgrades its tables

Three separate routines create the core tables, and they run at different times. That matters when a table is missing after a restore or a partial migration.

• Activation. TUTOR\Tutor::tutor_activate() is the plugin's activation hook. It calls Tutor::create_database(), which builds 15 CREATE TABLE statements and passes each to WordPress's dbDelta(). It does not run on a normal plugin update, only on activation, so deactivating and reactivating Tutor LMS is the simplest way to recreate a missing core table.
• Upgrades. TUTOR\Upgrader hooks admin_init. On 3.8.0 and later, upgrade_to_3_8_0() creates tutor_scheduler and tutor_order_itemmeta if they are missing, adds pre_tax_price to tutor_orders and adds item_type and item_details to tutor_cart_items. upgrade_to_3_8_2() adds indexes to tutor_earnings and normalises process_by to lower case.
• GDPR. TUTOR\GDPR\GDPR runs maybe_install_db() on init at priority 5. It compares the tutor_gdpr_db_schema_version option with its schema version (1.1.0) and creates the three consent tables when they differ.

Table names are registered as $wpdb properties in the Tutor constructor, for example $wpdb->tutor_quiz_attempts and $wpdb->tutor_orders. Use those properties in your own queries instead of hard-coding the prefix. The constructor also registers aliases for Pro's four subscription tables, even though the free plugin never creates them.

Quiz tables: questions, answers and attempts

Quizzes are tutor_quiz posts, but their questions are not posts. They live in four tables.

• tutor_quiz_questions: question_id, quiz_id (the quiz post ID), question_title, question_description, answer_explanation, question_type, question_mark, question_settings and question_order.
• tutor_quiz_question_answers: the options for each question, keyed by belongs_question_id and belongs_question_type, with answer_title, is_correct, image_id, answer_two_gap_match, answer_view_format, answer_settings and answer_order.
• tutor_quiz_attempts: one row per attempt with course_id, quiz_id, user_id, question counts, total_marks, earned_marks, start and end times, attempt_ip, manual review fields and result. It is indexed on course, quiz, user and result.
• tutor_quiz_attempt_answers: one row per answered question with quiz_attempt_id, question_id, given_answer, question_mark, achieved_mark, minus_mark and is_correct.

Values worth knowing when you report on these tables:

Two columns hold PHP-serialised data. attempt_info stores a snapshot of the quiz options at the time of the attempt, and given_answer is serialised for multi-answer question types such as multiple choice, ordering, matching and image answering. Simple SQL can count and average marks, but answer-level analysis needs PHP (maybe_unserialize()) or Tutor's own helpers. Note also that is_correct in tutor_quiz_attempt_answers is not binary since 4.1.0, so a report that sums it as a correct-answer count will over-count manually graded rows.

A read-only example that counts passed attempts per quiz for one course, using the registered table alias and a prepared query (not run on a live site; test on staging first):

function aio_tutor_passed_attempts_by_quiz( $course_id ) {
    global $wpdb;
    return $wpdb->get_results(
        $wpdb->prepare(
            "SELECT quiz_id, COUNT(*) AS passed
             FROM {$wpdb->tutor_quiz_attempts}
             WHERE course_id = %d AND result = %s
             GROUP BY quiz_id",
            absint( $course_id ),
            'pass'
        )
    );
}

E-commerce tables: orders, coupons, carts and customers

Since 3.0.0, Tutor LMS has a native checkout, and its data sits in nine tables. Sites that sell through WooCommerce keep their orders in WooCommerce instead; these tables then stay mostly empty apart from earnings.

• tutor_orders: user_id, order_type (single_order, subscription or renewal), order_status (incomplete, completed, cancelled, trash, pending), payment_status (paid, unpaid, failed, refunded, partially-refunded, pending), the price columns from subtotal_price to net_payment, tax, coupon and discount fields, fees, earnings, refund_amount, payment_method, transaction_id and the raw payment_payloads. Indexed on user, order type, payment status, order status and transaction ID.
• tutor_order_items and tutor_order_itemmeta: the line items (item_id is a course or plan ID) with regular, sale and discount prices, and their meta.
• tutor_ordermeta: key-value meta for each order.
• tutor_coupons: coupon_code (unique), coupon_type (code or automatic), discount_type, discount_amount, applies_to, total and per-user usage limits, purchase requirements and the GMT start and expiry dates.
• tutor_coupon_applications and tutor_coupon_usages: what a coupon applies to (reference_id) and which users have used it.
• tutor_carts and tutor_cart_items: the cart per user and its items, including the 3.8.0 item_type and JSON item_details columns.
• tutor_customers: billing name, email, phone, address, country, state and city per user.

Foreign keys: the detail that breaks partial restores

Unlike most WordPress plugins, Tutor LMS declares real MySQL foreign keys on its e-commerce tables. In 4.1.3 they are:

Practical consequences:

• Import order matters. Restore wp_users, wp_posts, tutor_orders, tutor_order_items, tutor_coupons and tutor_carts before their child tables, or disable foreign key checks for the import session.
• Deletes cascade at database level. Deleting a user row with SQL removes that user's carts and coupon usage rows without any WordPress hook firing. Deleting a course post the same way removes it from carts.
• Storage engine. MySQL foreign keys need InnoDB on both the parent and child table. If wp_users or wp_posts is still on MyISAM, as on some very old sites, convert it before activating Tutor LMS or importing these tables.

Finance, scheduler and GDPR tables

tutor_earnings records the revenue split for each sale: user_id (the instructor), course_id, order_id, order_status, the course price totals, instructor_amount and instructor_rate, admin_amount and admin_rate, commission_type, fee deductions and process_by. The class constants for process_by are tutor and woocommerce, so the column tells you which checkout created the row. tutor_withdraws holds instructor withdrawal requests: amount, method_data, status (new requests start as pending) and timestamps.

tutor_scheduler is a generic queue: type, reference_id, scheduled_at_gmt, status (default processing), a payload and the users who scheduled it and are its target. In 4.1.3 its main user is the Pro gift-course feature, which writes rows with type set to gift_course.

The three GDPR tables were added in 4.0.0:

• tutor_legal_consents: consent definitions with consent_title, display_on, consent_message, a JSON consent_map, version, consent_method, is_active and JSON settings.
• tutor_legal_consent_logs: legal_consent_id, action and JSON old_data and new_data for each change.
• tutor_user_consents: one row per consent given, with user_id, user_email, a snapshot of the label and links, version, consent_method, ip_address, user_agent, source and created_at_gmt.

The consent tables use the JSON column type, so the database server must support it. Treat tutor_user_consents as evidence: keep it in backups and do not truncate it during cleanups.

Tables added by Tutor LMS Pro add-ons

Pro tables are created when the matching add-on is switched on, not when Pro is activated. Several are created through hooks named tutor_addon_before_enable_{add-on path} or tutor_addon_after_enable_{add-on path}.

The add-on on/off state is stored in the tutor_addons_config option. If you enable add-ons by copying that option from another site instead of using the Add-ons screen, the enable hooks never fire and the tables they create are missing. Toggle the add-on off and on again to create them.

What is not in a custom table

Most "where is X stored" questions about Tutor LMS have an answer outside the tables above:

This split is why a "completion report" in Tutor LMS joins wp_posts, wp_usermeta and wp_comments rather than reading one table, and why a backup of only the tutor_* tables is not a usable backup. Our Tutor LMS architecture overview covers the post hierarchy in more depth, and the LifterLMS database tables reference is a useful contrast if you are comparing data models.

Backups, migrations and uninstall

• Back up the whole database. Course structure and progress sit in core WordPress tables, so a Tutor-only export misses most of the learning data.
• Uninstall is partial. With the delete_on_uninstall setting on, Tutor::erase_tutor_data() drops only six tables: the four quiz tables, tutor_earnings and tutor_withdraws. The e-commerce, scheduler, GDPR and Pro tables stay behind and need manual cleanup if you are removing Tutor LMS for good.
• Serialised data and domain changes. attempt_info, given_answer and the tutor_option option contain serialised PHP, so use a serialisation-aware search-replace when you change domains.
• Moving platforms. If you are migrating to or from Tutor LMS, map the custom tables and the post, meta and comment data together. Our LearnDash to Tutor LMS migration guide shows how that mapping works in practice.

How we can help

If you need custom reports on Tutor quiz or order data, a clean migration, or an add-on that adds its own tables the right way, our LMS plugin development team works with the Tutor LMS data model every week. For the wider picture of building on WordPress LMS plugins, start with the WordPress LMS development guide.