"Data warehouse"-like SQLite store design

I am interested in designing a SQL-based (SQLite, actually) storage for an application processing a large number of similar data entries. For this example, let it be a chat messages storage.

The application has to provide the capabilities of filtering and analyzing the data by message participants, tags, etc., all of those implying N-to-N relationships.

So, the schema (kind of star) will look something like:

create table messages (
    message_id INTEGER PRIMARY KEY,
    time_stamp INTEGER NOT NULL
    -- other fact fields
);

create table users (
    user_id INTEGER PRIMARY KEY,
    -- user dimension data
);

create table message_participants (
    user_id INTEGER references users(user_id),
    message_id INTEGER references messages(message_id)
);

create table tags (
    tag_id INTEGER PRIMARY KEY,
    tag_name TEXT NOT NULL,
    -- tag dimension data
);

create table message_tags (
    tag_id INTEGER references tags(tag_id),
    message_id INTEGER references messages(message_id)
);

-- etc.

So, all good and well, until I have to perform analytic operations and filtering based on the N-to-N dimensions. Given millions of rows in the messages table and thousands in the dimensions (there are more than shown in the example), all the joins are simply too much a performance hit.

I am constrained to SQL and, specifically, SQLite.

I there some way I don't see to improve the schema, maybe a clever way to de-normalize it?

Or maybe there is a way to somehow index the dimension keys inside the message row (I thought about using FTS capabilities but not sure if searching the textual index and joining on the results will provide any performance leverage)?