Vindicar

Ну так у тебя второй запрос запршивает всех пользователей, без условия.
А вообще приведённый код не имеет смысла и не должен работать вообще никак.

for i in cursor.fetchone("SELECT ID FROM user_info WHERE RANK = '1'"):

Ты перебираешь столбцы в первой строке (fetchone), для которой RANK = '1'. Это при том, что запрос возвращает тебе только один столбец - ID. А ещё метод fetchone() не принимает параметров. Ты пропустил вызов execute()?

Потом ты почему-то берёшь 0й символ этого столбца. Если он равен 1 (а он не будет равен 1, так как это символ, а не число).
Потом ты перебираешь всех пользователей, и отправляешь им сообщения (при этом у тебя в вызове send_message() две опечатки - в имени переменной и незакрытая скобка).

А ещё у тебя отступы кривые - почему for i с отступом?

В общем, по такой бредятине понять, в чём дело, нереально.

1. Что значит "одновременного вноса"? sqlite не потокобезопасна, но если ты используешь асинхронную библиотеку для телеги с дефолтной реализацией event loop, то у тебя никогда не будут выполняться 2 обработчика одновременно. Дефолтная реализация строго однопоточна, и проблем с sqlite не будет.
2. 500 человек - это не мера нагрузки. Самая примитивная мера нагрузки - обращений к базе в единицу времени.
А вообще более точно было бы проводить измерение времени выполнения разных частей обработчика события. Если бот потребляет значительную долю ресурсов своего хостинга и при этом проводит много времени обращаясь к БД - вот тогда стоит задуматься о смене БД. И даже тогда можно сначала посмотреть в сторону aiosqlite, чтобы не тормозить всего бота, пока запрос к БД выполняется.

Ну технически возможно: sqlite позволяет описывать user defined functions, которые можно вызывать внутри SQL-запросов - в том числе внутри триггеров. Вот только большой вопрос, что это за функции. С асинхронщиной могут быть проблемы.

Но честно, я бы лучше сделал простой поллинг. Запросил все записи позднее заданного времени, если такие записи есть - обработал, заменил заданное время на самое позднее из этих записей. Повторять раз в пять минут.
Да, время реакции медленнее, но зато код куда понятнее, и проще портируется на другую БД, если что.

def user_exists(self, user_id):
    with self.connection:
        ...
def add_user(self, user_id):
    with self.connection:

По выходу из блока with соединение закроется. Второй блок with его уже не переоткроет.
В таких ситуациях блок with использовать не надо.

Хранишь отдельно строку запроса и отдельно список значений.
Инициализируешь строку запроса SELECT * FROM table WHERE (1 = 1) - тогда у тебя будет корректный запрос и при наличии, и при отсутствии параметров.
Затем для каждого параметра проверяешь, если он был передан - к строке запроса добавляешь f'AND ({paramname} = ?)' (где paramname это имя параметра), а в список значений добавляешь в конце значение этого параметра. Если не передан - не делаешь ничего.
Тогда у тебя в конце будет строка вида

SELECT * FROM table WHERE (1 = 1) AND (b = ?) AND (c = ?)

, и к ней список значений, которые sqlite должна будет подставить вместо ?. Читай документацию на метод execute(), как это сделать.

fetchall() возвращает тебе список из кортежей.
Если ты не знаешь, что это такое - бегом учить. Это абсолютно базовые структуры данных в питоне, для создания сколь-нибудь сложной программы с ними (+ещё словари) нужно уметь работать не задумываясь.

1. Ты получил объект-курсор. У него нет строкового представления, поэтому пр ивыводе он отображается по умолчанию - <Cursor object at адрес-объекта-в-памяти>
Чтобы получить выбранные данные, нужно вызывать методы fetchone() или fetchall().
2. Если ты делаешь запрос к БД, который возвращает данные (неважно какие), получить их придётся как описано выше. Что это за данные - сами строки, какая-то агрегатная функция, или еще что - не важно. Даже если выполнишь запрос вида SELECT 123;, всё равно результат придётся вытаскивать через fetchone()/fetchall().
3. SUM(id) вернёт тебе сумму всех идентификаторов строк в таблице, а не количество строк в ней. Используй COUNT(*).

1. await так не пишется.
x = await asyncio.create_task(startq(message))
2. Зачем ты делаешь await?
asyncio.create_task() создаёт корутину, которая будет выполняться конкуррентно с текущей (как бы параллельно)
await приостанавливает выполнение текущей корутины, пока не завершится вызываемая (справа от await).
Т.е. await create_task(...) - это не очень осмысленно: сначала запускаешь параллельную корутину, а потом всё равно стоишь и ждёшь её.
Если тебе нужно запустить корутину startq() и дождаться её выполнения (ну и получить возвращаемое значение) - пиши просто x = await startq(message)
Если тебе нужно запустить корутину startq() и пусть она дальше выполняется сама по себе, тебе от неё ничего не надо - достаточно будет asyncio.create_task(startq(message))

Я подозреваю, что создалась у тебя не таблица, а файл базы данных.
Что бы создать таблицу, используй db.create_tables([Character])

f'''INSERT INTO {table_name}(date, id, username)
                    VALUES('{date}', '{user_id}', '{username}')'''

Вот почему бы не почитать хоть какой-нибудь туториал или официальную документацию(начиная со слов "SQL operations usually need to use values from Python variables")?
Я понимаю динамическое имя таблицы (хотя это тоже сомнительный ход), но уж параметры-то можно вставлять по-человечески.

А вообще, выбери что-то одно. Если ты осваиваешь SQL, не выделывайся с динамической генерацией запросов, освойся с простыми вещами для начала. Если нет - используй ORM, тот же peewee для начала, пусть он за тебя генерит запросы.

Ну и до кучи, как ты проверяешь, что в базу ничего не добавляется?

У тебя противоречия в запросах к БД. Для начала ответь на такие вопросы:
1. Сколько серверов будет обслуживать бот - один или несколько?
2. Сколько ролей можно покупать на сервере?
3. Баланс пользователя будет свой на каждом сервере или общий?
Исходя из этого и нужно проектировать БД.

Если ту не установил первичный ключ для таблицы, в ней могут быть одинаковые записи.

fetchall() возвращает список кортежей, это одна из базовых структур данных в питоне. Прочитай, что это такое, а потом уже берись за базы данных.