DAnalytics
Discord analytics, stored by shape.
PostgreSQL for the relational side, TimescaleDB for the time series, Grafana-style boards on top. The one product that breaks the naming scheme.
What it is
Analytics for Discord servers, self-hostable, and privacy-first by construction rather than by promise.
It is the one product that breaks the naming scheme. Everything else in the line starts with G.
Stored by shape
The design decision worth stating is that data goes where its shape belongs.
PostgreSQL holds the relational side. TimescaleDB holds the time series, because message and voice activity is time series data and storing it in ordinary tables means paying for that mistake at every query. Grafana-style boards sit on top.
That sounds obvious written down. It is not what most analytics tools do, and it is the reason this one can answer questions about a year of activity without a scheduled rollup job quietly lying to you.
How it fits together
Three processes with a strict rule between them.
A discord.js bot ingests gateway events under a sharding manager. It validates each payload and enqueues it. The bot writes nothing to the database directly.
A worker consumes those queues, runs the PII pipeline, and does batched inserts. The workers own the database.
A Next.js dashboard serves the UI over tRPC and REST, with live updates pushed over WebSockets on the same port as the app itself.
Keeping the bot out of the database is what makes the ingest side survivable. A gateway client is at the mercy of someone else's event volume. If it also held database connections, a busy day would take the warehouse down with it.
Privacy
There is a dedicated PII pipeline between ingest and storage, keyed separately. Fine-grained access control sits over the dashboards, not just over the login.
Analytics on a community is analytics on people. The self-hostable part and the privacy part are the same decision.
Running it
Three deployment paths, in order of how much infrastructure you want to own: a managed PaaS-style deploy through Nixpacks, either all-in-one or split into three services; docker-compose behind your own reverse proxy; or plain Node against a PostgreSQL with TimescaleDB and a Redis.
PgBouncer sits in front of PostgreSQL. Dashboards are provisioned as code.
Status
Built and working. Not currently the front of the queue, which is GControl and GPlatform.
Legal: Terms · Privacy notice · Processing agreement