Good instinct. A transactional database is the wrong tool for append-only event data at that volume: reads become very slow once the rows accumulate. This is exactly what OLAP engines are designed for.

• Built for events. Columnar storage, partitioning, and caching make it cheap to ingest millions of rows.
• Fast to query. Aggregations over huge tables stay quick, so storage size and query time are no longer a concern.

Store everything, and stop worrying about volume or query latency.

Use ClickHouse. Their managed cloud is the easiest option, but it is more than you need and expensive at this stage. ClickHouse is open source, so rent a basic server from a provider that only charges for what you use, and install ClickHouse on it.

Then build three pieces:

• Model the events separately from your app database. A dedicated DocumentEvent model points to 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 send them in batches to a single endpoint, instead of sending one request per mouse movement.
• Ingest asynchronously. That endpoint only accepts the batch and immediately returns OK. A queued job then converts it to ClickHouse's format and inserts it.

Put the read side behind a stats service that queries ClickHouse directly. Writes feel instant to the reader, and your dashboards read directly from the OLAP engine.