You built a SaaS product. Users are signing up. But you have no idea what they're actually doing inside it — which features they use, when they drop off, who's about to churn, or why some users stick and others don't.
The data exists. It's sitting in your database right now. But getting to it means writing SQL, which you don't know, or waiting on an engineer, who has a backlog.
This guide is for founders and product managers who want real product analytics from their own database — without learning SQL and without paying for a separate event-tracking tool.
The metrics that actually matter for early-stage SaaS
Before you build dashboards, get clear on what you're measuring. For most SaaS products, these five metrics tell you everything:
Daily/Weekly Active Users (DAU/WAU): Are people coming back? Declining DAU is the earliest warning sign before churn shows up in revenue.
Activation rate: What percentage of new signups complete the action that makes them likely to stick around — the "aha moment"? Low activation kills growth before it starts.
Feature adoption: Which features do people actually use? If you built five features and only one gets used, that's product direction telling you something.
Retention: Of users who signed up 30 days ago, how many are still active? This is the number that predicts your company's trajectory better than anything else.
Churn: How many paying customers cancel each month, and why? The "why" usually shows up in behavior patterns before it shows up in cancellations.
All of this data is already in your database. The problem is access.
Why most analytics tools don't solve your problem
When non-technical founders search for product analytics, they usually find two categories of tools: event-tracking platforms and BI tools. Both have serious problems.
Event-tracking platforms: Mixpanel, Amplitude, Heap
These tools work by instrumenting your frontend with tracking code. Every user action — button click, page view, feature use — gets sent to their servers as an "event".
The problem: setup takes days of engineering work. You have to define events, write tracking code, and wait weeks for enough data to be meaningful. If you didn't instrument something six months ago, you can't analyze it today.
Worse: you're paying to store a copy of data that already exists in your database. Mixpanel starts at $28/month and gets expensive fast based on event volume.
BI tools: Metabase, Looker, Power BI
BI tools connect directly to your database, which is better. But they're built for data analysts. To build a useful dashboard in Metabase, you either need to write SQL or spend hours learning their query builder — which is essentially SQL with a UI.
They're also slow to set up. You need someone to model your data, create the right tables/views, and build reports. That's weeks of work, not hours.
A third option: query your database in plain English
What if you could skip both approaches — no event instrumentation, no SQL learning — and just ask your database questions like you'd ask a colleague?
"How many users activated last week?"
"What's our 30-day retention for users who signed up in May?"
"Which features did churned users never use?"
"Show me accounts that haven't logged in for 14 days."
This is what AI for Database does. You connect your database, and you ask questions in plain English. It generates the SQL, runs it, and shows you the answer.
No event tracking needed. No SQL. No waiting on engineers. Your existing data, accessible immediately.
What you can track without SQL
Once your database is connected to AI for Database, here are real examples of what you can ask:
Active users: "How many unique users logged in this week vs last week?"
Activation funnel: "What percentage of users who signed up in June completed their first [key action] within 7 days?"
Feature usage: "Which features have fewer than 10% of active users used in the last 30 days?"
Retention cohorts: "Of users who signed up in April, how many were still active in May and June?"
At-risk accounts: "Show me all accounts on a paid plan that haven't logged in for more than 21 days."
Churn signals: "What did churned users have in common — which features did they never use?"
Each of these becomes a saved dashboard card that refreshes automatically. Your team sees live data without anyone running queries.
How to get started in under 30 minutes
Getting connected is fast. Go to aifordatabase.com, create an account, and connect your database using your connection string. AI for Database supports PostgreSQL, MySQL, Supabase, MongoDB, BigQuery, and most other databases your SaaS product might be running on.
Once connected, start asking questions. You don't need to set anything up — the AI reads your schema and figures out what tables and columns are relevant to each question.
When you find a query you want to monitor regularly, save it as a dashboard. It refreshes automatically, so you get a live product health view without any manual work.
You can also set up workflow automations: get a Slack alert when a key metric drops below a threshold, or trigger an email to a customer success rep when an account goes quiet. All without Zapier, no-code tools, or custom integrations.
What about data that isn't in your database?
Fair question. If you want to track frontend behavior like which buttons users click or where they rage-click, that data has to be instrumented — it doesn't live in your database by default.
But for most SaaS products, the most important product metrics are already there: signups, logins, subscription events, feature usage records, support tickets, API calls. The data exists. You just can't access it without SQL.
For those use cases, AI for Database covers you completely. For click-level frontend tracking, a lightweight tool like Plausible or a single Google Analytics property alongside aifordatabase usually covers everything a founder needs.
The real cost of not having this
Every week you're flying without product data, you're making product decisions based on gut feel instead of behavior. You build features users don't want. You miss churn before it happens. You can't see which user cohorts succeed and which fail.
The cost of a natural language database tool is a rounding error compared to the cost of one wrong product bet.
Set this up before you make your next roadmap decision.