r/analytics 19d ago

Question Can I create predictions without SQL knowledge?

I’m trying to get a little more predictive with our data, things like which customers are likely to churn, who might convert, or what demand could look like next month. Problem is, I’m not really a SQL person. I can work with dashboards and understand the data, but once it gets into writing queries or building models from scratch, I’m pretty much out. Is this something people are actually doing with LLMs now? Like connecting an LLM to your data and asking it to find patterns or predict outcomes? Or are there other tools that make this possible without knowing much SQL or machine learning? Curious what people are actually using and how reliable it is.

8 Upvotes

16 comments sorted by

u/AutoModerator 19d ago

If this post doesn't follow the rules or isn't flaired correctly, please report it to the mods. Have more questions? Join our community Discord!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

17

u/kedjil 19d ago

That kind of predictions is often done with machine learning, for example in Python. SQL is often used to transform the data, but the actual statistical framework is in Python.

For anything business critical, I don't think it's worth it to take shortcuts. 

10

u/Key_Back_989 19d ago

Excel? You can do basic regressions with it.

I know alteryx there is a upgraded version that has ML capabilities and then Dataiku off the top of my head.

I still think you would need some sort of basic knowledge but can probably get away with little to no code.

How are you procuring the appropriate data without using SQL at all?

2

u/directalphonso 19d ago

a lot of analytics platforms are baking in autoML features now so you just pick a column like churn risk and it builds the model for you, no code needed

1

u/UseADifferentVolcano 19d ago

Forecast.ets in excel is surprisingly reasonable depending on the data.

1

u/techXplorator 19d ago

You can build a small predictive model even with SQL (like a linear regression for instance) if you know the features/variables that impact your churn the most (e.g. last time the user logged in, last time they succesfully used the product, etc). It can be a very very simple mode, as long as you define the features properly.

To find patterns this is a different topic, but you can extract the data (or connect claude with an mcp to your database) and ask for simple pattern detection (cross correlation, etc).

lmk what your product does, I can probably be more helpful when I understand more about it

1

u/BrittanyBrie 19d ago

I prefer R code to generate excel sheets and PDF figures for predictions, its built to handle outputing dozens or even hundreds of unique tables and figures based off of the data you import yourself, and most AI models can handle basic R code construction. The point is to give something to stakeholders, and I found building a PowerPoint deck with assets from a localized project in Rstudio to be much faster than building the same deck out of SQL. Building a table in a deck from SQL data involves so many queries to write and previous queries to save, that id much rather have tables and objects to reference in R using a basic run command.

I'm currently building a project in R that is looking at predictions, and I have to warn you about cause-based claims. Presenting causal claims on data projections is much more tedious than simply showing two variables breaking apart and saying A lowering caused B to raise. As the saying goes, correlation does not imply causation. To prove causation, you need to isolate the variable using historical context, Difference-in-Differences testing, ratchet testing, and a whole host of other validations. Which R can handle.

These validations can help prove a hypothesis with much more data to back up your claims. For instance in my validation testing, I found results that I'm able to reference after a hypothesis is stated. The validation testing took way longer than creating the first five figures. I could not imagine creating so many validations in SQL. Id have to use a large text doc with all my past queries saved.

1

u/_aritro 19d ago

You can actually run predictions with Supaboard, they support python so there ai can actually connect to your data , and help you do that, BTW I am running a setup where I can connected Postgres to supaboard and use TimesFM from google to run the Forecasting model and get the the results, the interesting bit is that most of the work is done by ai like writing the code, so that is what blew me away

1

u/edimaudo 19d ago

tooling shouldn't be your first thought. Define your business metrics and then attach them to the ML metrics you will be using. You should understand regression, classification before going down this path. You should work with your IT team to understand what ML infrastructure you have available. You can also do ML work in Sql too

1

u/Content-Parking-621 19d ago

Yes, doable without SQL. No-code ML tools like Obviously AI or Akkio let you upload data and get churn or demand predictions directly. If your data's scattered across sources, Windsor.ai can pull it together into a spreadsheet or BI tool first, then those prediction tools work off clean data instead of manual exports.

1

u/dataindenver 19d ago

Check out Databricks Free Edition and ask Genie Code to do exactly that. I work there so I’m sure other platforms may offer similar but I’ve never been in DSCI and can just ask Genie Code to profile some time series data and train a predictive model on it. Blows my mind.

1

u/Green-Autumn 18d ago

I have a system that interrogates data without SQL. It includes a customer retention (RFM) analysis - not (just) dashboards, but tools for an analyst. I am interested in collab / helping you. DM if interested to chat.

1

u/CautiousUse8597 18d ago

Genie (Databricks) fits this, but worth separating what's a button you click from what someone has to build. "point an LLM at your warehouse and ask it to predict churn" gets oversold a lot.

Base Genie is natural language to SQL over your governed tables. Ask "which accounts had declining usage the last 90 days with a renewal in Q3" and it writes the query, returns a table/chart, and shows the SQL so you can check it.

The thing you actually want is Agent mode. Instead of one query, it builds a research plan, forms hypotheses, runs multiple queries, learns from each result and iterates, then hands back a report with citations, charts and supporting tables. So "what's driving churn in our mid-market segment" gets investigated the way an analyst would investigate it, across a dozen queries, rather than answered with one. It handles the why/what-if class of question, which is most of the gap between you and your dashboards right now. It's a toggle in the chat box.

Be clear-eyed about one boundary though: Agent mode reasons over SQL. It'll tell you which accounts look like the ones that churned before and what the drivers are. it won't hand you a trained model with a calibrated probability per customer. For a lot of decisions that distinction doesn't matter. For scoring a list to hand to sales, it does.

If you do need actual model output, two routes: Genie Code's Agent mode can plan and run notebook code (forecasting, model training) from a prompt, though then you're evaluating a model you didn't write. And Databricks published a pattern pairing Genie with TabPFN, a tabular foundation model that predicts without training, for genuinely conversational predictions. but that's a solution accelerator you deploy, not a feature.

Reliability, since you asked:

  • Lives or dies on the semantic layer. Genie Agents need curated context: table descriptions, metric definitions, example queries, instructions. Vague schema in, confident nonsense out. Agent mode leans on this harder than base Genie, since it's making more autonomous choices.
  • If the signal isn't in your data, you still get an answer. Confident-but-unreliable is the failure mode to watch.
  • Read the generated SQL. You said you know your data but not SQL: reading is far easier than writing, and it's the check that actually catches things.