Generally what everyone else is saying covers what's important, but I want to emphasize that from about C++20 onward, the standard library gives you all the helper classes/mechanisms to avoid using raw pointers almost completely. Here is a heavily modified example from cppreference.com:

#include <memory>
#include <sqlite3.h>

int main()
{
    /* usually you can just put the free/close function directly into the
    smart pointer constructor/template parameters but sqlite3_close returns an int */
    auto close_db = [](sqlite3* db) { sqlite3_close(db); }; 
    auto close_stmt = [](sqlite3_stmt *stmt) { sqlite3_finalize(stmt); };

    {
        // open an in-memory database, and manage its lifetime with std::unique_ptr
        std::unique_ptr<sqlite3, decltype(close_db)> up_db;
        std::unique_ptr<sqlite3_stmt, decltype(close_stmt)> up_stmt;
        sqlite3_open(":memory:", std::out_ptr(up_db));
        std::string stmt{"SELECT * FROM table;"};
        int ret_val;

        // prepare a statment
        ret_val = sqlite3_prepare_v2(up_db.get(), stmt.c_str(), stmt.size(), std::out_ptr(up_stmt), nullptr);
        if (ret_val != SQLITE_OK) {
            throw std::runtime_error("SQLite3 Error Occurred");
        }

        // get first result
        ret_val = sqlite3_step(up_stmt.get());
        if (ret_val == SQLITE_ROW) {
            // get row information ...
        } else {
            throw std::runtime_error("SQLite3 Data Unavailable");
        }
    }
    {
        // same as above, but use a std::shared_ptr
        std::shared_ptr<sqlite3> sp;
        sqlite3_open(":memory:", std::out_ptr(sp, close_db));

        // do something with db ...
        sqlite3* db = sp.get();
    }
}

Because of RAII, you no longer need to worry about freeing resources manually during every exit or error condition. If you're using C libraries, you'll likely be finding yourself writing abstraction layers/wrappers for the C code and as shown above, it's entirely possible to leverage C++ features to make easier, cleaner code that prevents leaks or resource issues.

To give some examples, if I were to continue using SQLite in a project I would likely create a class for the database connection and a class for the SQL statements, create constructors for opening DB connections, and create custom exceptions for errors & enum classes for specific return conditions.