Should I use AskYourDatabase Desktop or the Website Chatbot?

Updated

Use Desktop if you are an analyst, operations person, or business user who wants to ask your own database questions from a Windows or macOS app. Use the Website Chatbot if you are a product team that wants to put database questions inside a website or customer portal for your users. They are separate products, so the choice depends on who needs the answers and where they will ask. If you have hosting or data-handling requirements, private deployment is a separate enterprise discussion.

The core difference: who asks, and where

AskYourDatabase turns questions about your database into SQL, answers, and charts. Both products do that, but they sit in different places.

Dimension Desktop Website Chatbot
Built for Analysts, operations teams, business users Product teams adding questions to a website or customer portal
Where it runs Windows or macOS app on your computer Embedded chat interface inside your application
Database access Your computer needs database access Connect the chatbot to approved data
Setup focus Connect from your computer, then ask Configure the chatbot, integrate the interface, plan authentication
Access control concern Use a limited database account Plan user-level data access before rollout
Best when You want to analyze data yourself Your users need answers without touching SQL

Choose Desktop if you want to analyze data yourself

Desktop is the fit when the person asking the question is also the person who needs the answer. You connect from your computer, ask a question, inspect the SQL and results, then ask a follow-up or request a chart.

Two conditions matter before you start:

  • Your computer needs database access. Local connections do not mean offline AI. Questions and necessary response data can reach a model provider through the AI gateway, so "local" describes the connection, not the whole processing path.
  • Start with read-only permissions. For analysis, use a database account limited to the tables or reporting views you need.

A practical workflow, based on how the product describes its own process:

  1. Connect approved data. Use a limited database account and follow the connection guide for PostgreSQL, MySQL, SQL Server, BigQuery, or another supported engine.
  2. Explain your business terms. Define revenue, active customers, date ranges, and table relationships. Add verified SQL examples and schema context so a familiar business phrase maps to the intended data.
  3. Check, then explore. Compare the first answers with a trusted report. Inspect filters, joins, and totals before relying on the result.

The common failure point is step 3. If "revenue" is not defined the same way in your schema as in your head, the SQL will be valid but the answer will be wrong. Verified SQL examples and schema context are what close that gap.

Choose the Website Chatbot if your users need answers

The Website Chatbot is for product teams adding database questions to a website or customer portal. You configure a chatbot and connect it to approved data, then integrate the chat interface into your application.

The setup work is different from Desktop in one important way: you are exposing data to people who are not you. The product guidance is explicit here — plan authentication and user-level data access before rollout, and test that each user can retrieve only the records they are allowed to see.

That test is the real acceptance criterion. A chatbot that answers correctly but shows one customer another customer's rows has failed, regardless of how good the SQL is.

What about private deployment?

Private deployment is not a third option you pick from the same menu. It is an enterprise discussion for organizations with hosting or data-handling requirements. You agree on application hosting, the model endpoint, network access, and operational responsibilities with the enterprise team.

Two limits to keep in mind:

  • Hosting the application yourself can still involve external model API calls.
  • A locally hosted model is a separate deployment scope.

So "private" does not automatically mean "no data leaves your environment." Confirm which parts stay inside before you treat it as a compliance answer.

How to decide

Ask these in order:

  1. Who needs the answer? Your own team → Desktop. Your customers or portal users → Website Chatbot.
  2. Where will they ask? In a desktop app → Desktop. Inside your product → Website Chatbot.
  3. Can the asker reach the database directly? Desktop requires database access from the user's computer. If that is not possible or not appropriate, the Website Chatbot model fits better.
  4. Do you need per-user access control? If yes, budget for authentication and user-level data access planning before rollout — this is not optional for the chatbot.
  5. Do you have hosting or data-handling constraints? Then start an enterprise conversation about private deployment, and clarify the model endpoint and whether a locally hosted model is in scope.

If you are still weighing cost and usage, review plans and usage allowances, or compare AskYourDatabase and BlazeSQL.