Right instinct. A transactional database is the wrong tool for append-only event data at that volume: it will choke at read time once the rows pile up. This is what OLAP engines are built for.

• Built for events. Columnar storage, partitioning, and caching make ingesting millions of rows cheap.
• Fast to read back. Aggregations over huge tables stay quick, so storage size and retrieval time stop being your problem.

Store everything and stop worrying about volume or query latency.

Go with ClickHouse. Their managed cloud is the easy path, but overkill and pricey at your stage. It's open source, so rent a plain server from a host that only bills for what you run, and put ClickHouse on it.

Then three pieces:

• Model the events apart from your app DB. A dedicated DocumentEvent model points at the ClickHouse connection, so you write Eloquent-style queries for stats without ever touching your main database.
• Buffer on the client. Collect events in a JavaScript buffer in the browser and flush them in batches to one endpoint, instead of firing a request per mouse move.
• Ingest async. That endpoint does nothing but accept the batch and return OK with zero latency. A queued job then reshapes it into ClickHouse's format and inserts it.

Wrap the read side in a stats service that queries ClickHouse directly. Writes stay instant for the reader, and your dashboards read straight off the OLAP engine.