Open Analytics

Open-source website analytics with Supabase. Track page views, visitors

Hey Uneed.best 👋

We built Open Analytics because most analytics tools felt either too heavy (Google Analytics), too closed, or too expensive for indie makers and small startups.

Open Analytics is a lightweight, privacy-friendly analytics platform that runs directly on your own Supabase database — no separate tracking server required.

✨ What makes it different?

• Your data stays fully yours (directly in Postgres)
• Self-hosted & open source (MIT)
• No complex cookie banners
• Realtime 3D visitor globe 🌍
• Simple script setup in minutes
• Direct SQL access to all events
• Built for startups, side projects, blogs & SaaS apps

Instead of locking your analytics behind a SaaS black box, we wanted to make analytics transparent, hackable, and developer-friendly.

Would love your feedback, questions, and feature ideas ❤️

About Open Analytics

Open Analytics is a marketing product listed on Uneed, available for free. It's tagged with Analytics. See the best Analytics products for related options.

Frequently asked questions about Open Analytics

What is Open Analytics?

Open Analytics is open-source website analytics with Supabase. Track page views, visitors.

Is Open Analytics free?

Yes, Open Analytics is free to use.

What are alternatives to Open Analytics?

Discover similar analytics products in the Uneed directory.

What category does Open Analytics belong to?

Open Analytics is listed under Marketing on Uneed.

What users say about Open Analytics

SpinHire
Direct SQL access to the events is the bit I'd actually use. On our job board the raw logs turned out to be mostly not people: AI crawlers and scrapers hit listing pages all day, and the headless-browser ones run the JS snippet like any visitor, so a script-based tracker counts them as sessions and a slow week can look like a traffic spike. Having the raw rows in our own database is what let us spot it and write the filter at all. Do you drop suspected bots before the insert, or store everything and filter them out in the views, so people can change the rules later?

Read all 1 review

User reviews

SpinHire@spinhire · Sep 30, 2026

Direct SQL access to the events is the bit I'd actually use. On our job board the raw logs turned out to be mostly not people: AI crawlers and scrapers hit listing pages all day, and the headless-browser ones run the JS snippet like any visitor, so a script-based tracker counts them as sessions and a slow week can look like a traffic spike. Having the raw rows in our own database is what let us spot it and write the filter at all. Do you drop suspected bots before the insert, or store everything and filter them out in the views, so people can change the rules later?

View