If you are building RAG applications or managing vector databases, you’ve probably hit this exact wall: you go to upsert your chunks, and the job fails because your metadata payload is too large. Pinecone, for example, has a strict 40KB limit.

It's incredibly frustrating when an entire pipeline crashes just because you wanted to store chunk_text, raw_html, and a summary alongside your vectors. The standard "fix" is to write messy custom scripts to strip out the heavy fields, which breaks your workflow and is hard to maintain.

I got tired of writing hacky workarounds, so I built a native Python solution.

I just open-sourced vectormeta, a tool to scan, validate, and fix vector DB metadata before you upsert.

How it works: Instead of losing your data, vectormeta analyzes your JSON/JSONL records in UTF-8. It keeps the filterable fields you actually need (like source, page, doc_id, tags) directly in the vector DB record. Then, it automatically moves the heavy, storage-heavy payloads (like HTML or massive text chunks) into local sidecar stores (SQLite, JSON, or FileStore).

It leaves behind a lightweight content_ref so you stay well under the 40KB limit, but you never lose your source data.

You can use it as a CLI tool (vectormeta scan records.json --target pinecone) or drop safe_upsert directly into your Python ingestion pipelines.

If you are building in the AI space and fighting metadata limits, you can check it out on GitHub: https://github.com/Achal13jain/vectormeta or run pip install vectormeta.

What vector DB are you currently using, and how do you normally handle massive chunk metadata?

So that's what I did. Took a stock prediction model trained on real Yahoo Finance data, put it on AWS EC2, and wrapped it with a FastAPI endpoint. You hit /predict/TCS.NS and it tells you if the model thinks tomorrow goes up or down. Not localhost — an actual server with a public IP.

If you've never touched AWS, that's fine. I was googling "what is a .pem file" two weeks before writing this.

What We're Building

Two years of TCS stock data pulled from Yahoo Finance. A Random Forest classifier trained on it. That model sitting on an EC2 instance behind a FastAPI endpoint. You give it a ticker, it gives you a direction. Nothing fancier than that.

Pulling Data and Training the Thing

Get the installs out of the way first — pip install yfinance pandas scikit-learn joblib fastapi uvicorn.

yfinance is almost suspiciously easy. No API key, no signup, no rate limit dashboard. You give it a ticker, it hands you two years of daily prices. I kept waiting for the catch and there isn't one.

Here's the full pipeline from pulling data to saving the trained model. I'm putting it all in one block because that's honestly how I wrote it — one script, ran it locally, checked the accuracy, moved on.

import yfinance as yf
import pandas as pd
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import accuracy_score
import joblib

stock = yf.Ticker("TCS.NS")
df = stock.history(period="2y")

# moving averages, price momentum, volatility, volume shifts
df['MA_7'] = df['Close'].rolling(7).mean()
df['MA_21'] = df['Close'].rolling(21).mean()
df['Price_Change'] = df['Close'].pct_change()
df['Volatility'] = df['Close'].rolling(7).std()
df['Volume_Change'] = df['Volume'].pct_change()
df.dropna(inplace=True)

df['Target'] = (df['Close'].shift(-1) > df['Close']).astype(int)
df.dropna(inplace=True)

cols = ['MA_7', 'MA_21', 'Price_Change', 'Volatility', 'Volume_Change', 'Close']
X, y = df[cols], df['Target']

cutoff = int(len(df) * 0.8)
model = RandomForestClassifier(n_estimators=100, random_state=42)
model.fit(X[:cutoff], y[:cutoff])

print(f"Accuracy: {accuracy_score(y[cutoff:], model.predict(X[cutoff:])):.2%}")
joblib.dump(model, 'stock_model.pkl')

Few things worth mentioning here. Raw closing prices as input is useless — the model just memorizes numbers. The rolling averages and volatility give it something to actually learn from.

I tried predicting exact prices at first. Regression. Terrible idea. The model would spit out a number like 3847 when the real price was 3902 and I'd have no idea if that's acceptable or not. Reframing it as a binary up/down question made evaluation straightforward — either it got the direction right or it didn't.

Also, don't use train_test_split with shuffle on time series data. I almost did out of habit. If you shuffle, 2024 rows end up in training while 2023 rows are in test. Your accuracy looks amazing because the model literally saw the future. Chronological split only.

That first dropna() matters too — rolling windows produce NaN for the first ~20 rows and sklearn won't warn you about it. It just trains on garbage quietly.

AWS Setup

Go to aws.amazon.com, make a free account. Free tier gives you 12 months of t2.micro EC2. Small machine, plenty for this.

EC2 dashboard, Launch Instance. Ubuntu Server 22.04 LTS, t2.micro, create a new key pair and download the .pem file. You cannot re-download this — I lost my first one. In the security group, allow SSH on port 22 and add custom TCP for port 8000 from anywhere.

Once it's running, grab the public IP and SSH in:

chmod 400 your-key.pem
ssh -i your-key.pem ubuntu@your-instance-public-ip

That chmod 400 is required — SSH refuses the key if permissions are too open. First time you see a Linux prompt on a machine you don't own is a weird feeling.

Set up Python and transfer the model:

sudo apt update && sudo apt install python3-pip python3-venv -y
python3 -m venv ml-env && source ml-env/bin/activate
pip install fastapi uvicorn scikit-learn joblib pandas yfinance numpy

Open a second terminal on your local machine (keep SSH open) and copy the model over:

scp -i your-key.pem stock_model.pkl ubuntu@your-instance-ip:~/

Never used scp before this project — it's just file copy over SSH. The ~/ drops it in the home directory.

The API

Create app.py on the server and put this in:

from fastapi import FastAPI
import joblib, yfinance as yf, numpy as np

app = FastAPI()
model = joblib.load('stock_model.pkl')

@app.get("/predict/{ticker}")
def predict(ticker: str):
    try:
        df = yf.Ticker(ticker).history(period="60d")
        df['MA_7'] = df['Close'].rolling(7).mean()
        df['MA_21'] = df['Close'].rolling(21).mean()
        df['Price_Change'] = df['Close'].pct_change()
        df['Volatility'] = df['Close'].rolling(7).std()
        df['Volume_Change'] = df['Volume'].pct_change()
        df.dropna(inplace=True)

        row = df[['MA_7','MA_21','Price_Change','Volatility','Volume_Change','Close']].iloc[-1]
        features = row.values.reshape(1, -1)

        pred = model.predict(features)[0]
        prob = round(max(model.predict_proba(features)[0]) * 100, 1)
        direction = "UP" if pred == 1 else "DOWN"

        return {"ticker": ticker, "prediction": direction, "confidence": f"{prob}%"}
    except Exception as e:
        return {"error": str(e)}

@app.get("/")
def root():
    return {"status": "running"}

No separate get_features function — one route, no need to split things up.

Run uvicorn app:app --host 0.0.0.0 --port 8000 and try hitting it from your own machine:

curl http://your-ec2-ip:8000/predict/TCS.NS

You should get back something like {"ticker": "TCS.NS", "prediction": "UP", "confidence": "64.3%"}. First time I saw that come back from my own server I just sat there for a bit.

Keeping It Alive

Close SSH and uvicorn dies. I use screen for this:

sudo apt install screen -y
screen -S stock-api
source ml-env/bin/activate
uvicorn app:app --host 0.0.0.0 --port 8000

Ctrl+A then D to detach. Your server stays up even after you close the terminal. screen -r stock-api to get back in.

Cost

Zero. t2.micro is free for 12 months. yfinance is free forever. But stop the instance when you're done — EC2, select your instance, Instance State, Stop. A forgotten running instance drains free tier hours and AWS won't warn you.

Step Back

Someone can type a URL, hit your endpoint, on a server you set up, and get a prediction from a model you trained on 2 years of real market data. That covers data engineering, ML, API development, and cloud deployment in one project. Put the live link in your portfolio — it hits differently when the interviewer can actually click it.

What's Next

Part 4 runs this same thing on GCP and Oracle Cloud. Oracle's always-free tier gives you a permanent 24GB RAM server for nothing — sounds fake, it's not. We'll compare all three providers head to head.

Following along? Hit follow on Hashnode so Part 4 lands in your feed. Stuck on the AWS setup? Drop a comment — there's like 15 things that can go wrong with security groups alone.

When I was building my Disease Prediction System, my laptop gave up mid-training. Not metaphorically—it just hung. That’s when I turned to free cloud platforms. And the thing that surprised me most? I didn’t have to pay anything. Not a single rupee.

Here are the three I’ve actually used.

1. Google Colab—The One Everyone Starts With

Someone has probably already told you to "just use Colab." That advice isn't wrong.

Colab is Jupyter Notebook but running on Google's hardware. You open a browser tab, write code, run it — your laptop does almost nothing. And getting a free GPU takes literally three clicks.

Setting it up

Go to colab.research.google.com, sign in, and open a new notebook. Then:

Runtime → Change runtime type → T4 GPU → Save

To verify it worked:

import tensorflow as tf
print("GPU Available:", tf.config.list_physical_devices('GPU'))

If you see an empty list, restart the runtime and try again.

The Google Drive Trick

Every new Colab session starts completely fresh — no files, nothing. So instead of re-uploading your dataset every time, store it in Google Drive and mount it:

from google.colab import drive
drive.mount('/content/drive')

import pandas as pd
df = pd.read_csv('/content/drive/MyDrive/your-dataset.csv')

I wasted multiple sessions before I figured this out. Don't be me.

Where Colab Will Frustrate You

Step away for 90 minutes and your session is gone. Variables, progress, everything. I learned this during a 45-minute training run. Timed out. Started over.

Also, the free GPU isn't guaranteed. During peak hours you might silently get a CPU instead. Always check your runtime type before training.

Short version: Great for quick experiments. Not reliable for long runs.

2. Kaggle Notebooks—Honestly Underrated

Most people think of Kaggle as the competition platform and completely ignore the notebook environment. That's a mistake.

For my Disease Prediction project, the dataset I needed was already on Kaggle. No downloading, no uploading. Just click, add, done. That alone sold me.

Getting Started

Create a free account at kaggle.com → Create → New Notebook

Right panel → Session options → Accelerator → GPU P100 → Save

You get 30 hours of free GPU per week, consistent, no surprises. Compare that to Colab where you're kind of gambling each session.

Loading Datasets Directly

import pandas as pd

# datasets live at /kaggle/input/ — no uploading needed
df = pd.read_csv('/kaggle/input/disease-symptoms-dataset/dataset.csv')
print(df.shape)

For the Disease Prediction project, this saved me 30-40 minutes of downloading, unzipping, re-uploading nonsense every single session.

Saving Your Model

import joblib
joblib.dump(model, '/kaggle/working/disease_model.pkl')

Download it from the output panel on the right. Your notebook also auto-saves, unlike Colab.

Where Kaggle Falls Short

30 hours sounds like a lot until it's Wednesday and you've used it all. Internet is also off by default — enable it manually or pip installs fail silently, which is a confusing bug to debug.

Short version: More reliable than Colab, better for data-heavy work. Use this when Colab keeps letting you down.

3. Hugging Face Spaces — For Showing Your Work

This is where most ML beginners stop — they train a model, save a .pkl file, and it just sits on their laptop. Nobody sees it. Hugging Face Spaces fixes that.

It lets you wrap your model in a web UI and deploy it free. Think about it this way — if you send a recruiter your GitHub link, they have to clone the repo, set up the environment, install dependencies, and hope it runs. Nobody does that.

But if you send them a link and they can just type in symptoms and see a prediction in 5 seconds? That's a different conversation entirely.

Gradio is what makes that possible. And it's stupidly easy to set up.

Building a Demo with Gradio

import gradio as gr
import joblib

model = joblib.load('disease_model.pkl')

def predict(symptom1, symptom2, symptom3):
    result = model.predict([[symptom1, symptom2, symptom3]])
    return result[0]

gr.Interface(
    fn=predict,
    inputs=["text", "text", "text"],
    outputs="text",
    title="Disease Prediction System"
).launch()

That's the whole thing. Run it, Gradio hands you a URL, and your model is now a working web app. No HTML, no JavaScript, no backend setup. I genuinely could not believe how fast this worked the first time I tried it.

Deploying It

Go to huggingface.co/spaces → Create new Space → pick Gradio → upload your model and app file. It goes live at huggingface.co/spaces/yourusername/app-name. Free tier runs on CPU which is enough for demos.

Short version: Don't use this for training. Use it to turn a finished model into something people can actually interact with.

Which One Do I Actually Use?

Depends on where you are:

• Just learning / quick experiment → Colab. Low friction, just open and go.

• Real dataset, need reliable GPU → Kaggle. 30 hours a week, auto-saves, no upload headaches.

• Want to show your model to someone → Hugging Face Spaces. Build a Gradio app, deploy, share the link.

For my Disease Prediction project — started on Kaggle because the dataset was there, did some experimentation on Colab, planned the Gradio demo for Hugging Face. Three platforms, one project, zero rupees.

None of them are perfect. But together they cover everything you need at the beginner-to-intermediate level.

When they stop being enough — that's Part 3. We're moving to AWS with a real stock market dataset. Full setup, real code, step by step.

Following along? Hit follow on Hashnode so Part 3 lands in your feed. Questions about Colab or Kaggle? Drop them in the comments.

You're excited. You've got a dataset, a model plan and a cup of coffee. You start your Jupyter notebook, hit model.fit() and then your laptop fan gets really loud. The training is slow. The kernel crashes. Or worse. It runs for 3 hours. You get an error right at the end.

I have been there. When I started working with datasets that required deep learning models my laptop just couldn't keep up. It wasn't a skill problem. It was a hardware problem. That's when I started taking cloud computing seriously.

If you hit this wall too this series is for you.

Why Your Laptop Struggles with ML

Lets be honest about whats happening.

Most laptops are built for tasks like browsing and coding. They typically come with:

• 4–16 GB RAM: Okay for development not okay for loading a 10GB dataset

• A CPU Good at doing tasks one at a time not great at parallel computation

• No dedicated GPU (or a weak one): This is the real problem for deep learning

Here's the thing about Machine Learning and Deep Learning. These models don't just run computations they run millions or billions of computations at the same time. Matrix multiplications, gradient updates, backpropagation. All of this is parallel work. That's exactly what GPUs are designed for.

When you train a learning model on a CPU it's like trying to fill a swimming pool with a water bottle. It works. It'll take forever.

What Happens When You Push Your Laptop Hard

If you've trained any serious model locally you've probably experienced one or more of these:

Kernel crashes / Out of Memory (OOM) errors Your dataset or model simply exceeds your available RAM. Python throws an error. Your progress is gone.

Slow training A model that would take 10 minutes on a cloud GPU takes 6 hours on a laptop CPU. You can't iterate, experiment. Improve quickly.

Overheating and throttling Your laptop detects its running too hot. Automatically slows itself down to prevent damage. Training gets even slower.

You can't do anything Your entire machine is locked up running the model. No multitasking.

These aren't edge cases. They're the normal experience for anyone trying to do real ML work on consumer hardware.

So What Does "The Cloud" Actually Mean?

The word "cloud" gets thrown around a lot. Lets simplify it.

The cloud is simply someone else's powerful computer. One that you access over the internet.

That's it. When you run your model "on the cloud " you're renting time on a machine that lives in a data center. That machine might have:

• Hundreds of GB of RAM

• High-end GPUs like NVIDIA A100s or V100s

• Storage and network speeds

• The ability to scale up or down based on your needs

You write your code on your laptop send it to the cloud machine it does the computation and sends the results back. Your laptop is the controller. The cloud is where the real work happens.

The Three Types of Cloud ML Environments

Not all cloud options are the same. As someone getting started, it helps to know the three main categories:

1. Notebook Environments (Easiest to start)

These are browser-based platforms where you write and run code directly — just like Jupyter on your laptop, but with cloud hardware behind it.

Examples: Google Colab, Kaggle Notebooks, Deepnote

Best for: Learning, experimenting, small to medium projects, students

2. Cloud ML Platforms (More control)

These are dedicated ML services from major cloud providers. You get more control over hardware, storage, and deployment.

Examples: AWS SageMaker, Google Vertex AI, Oracle Cloud, Azure ML

Best for: Production models, larger teams, serious projects

3. GPU Rental Services (Pay for exactly what you need)

You rent a raw GPU instance and set everything up yourself. Maximum flexibility.

Examples: Vast.ai, Lambda Labs, RunPod

Best for: Heavy deep learning training, when you need a specific GPU

Free vs Paid — What you actually get

Here's something important for students and beginners: you don't need to spend money to start.

Several platforms offer genuinely free tiers that are more than enough to learn and build:

We'll do a deep dive into each of these in Part 2 of this series — with actual walkthroughs.

When Should You Move to the Cloud?

You don't need the cloud for everything. Here's a simple way to think about it:

Stay local when:

• You're learning the basics of ML (linear regression, small datasets)

• Your dataset fits comfortably in your RAM (under 1–2 GB)

• Training takes less than a few minutes

Move to the cloud when:

• Your dataset is large (images, video, NLP corpora)

• You're using deep learning (CNNs, Transformers, LLMs)

• Training takes more than 30 minutes on your laptop

• You want to deploy your model so others can use it

What's Coming Next in This Series

Now that you understand why local hardware falls short and what the cloud actually is, the next parts of this series get practical:

• Part 2: Free cloud options for small ML projects — Google Colab, Kaggle, and Hugging Face Spaces with hands-on walkthroughs

• Part 3: Deploying heavy ML models on AWS, GCP, and Oracle Cloud step by step

• Part 4: Which cloud platform should you pick? A comparison for ML beginners

The Bottom Line

Your laptop struggling with ML isn't a sign that you're doing something it's a sign that you're doing something real. Real datasets are large. Real models are heavy.. The cloud exists precisely to solve this problem.

The good news? Getting started with ML is free and its more accessible than most tutorials make it seem. Stick with this series and, by the end you'll be running your models on GPUs without paying a rupee.

If you found this helpful follow me on Hashnode for Part 2. Have questions. Hit a specific issue with your own setup? Drop it in the comments. I read everything.