30 Years of MySQL: Version History and Feature Evolution

If you’ve used the internet at all over the last twenty-five or thirty years, you’ve almost certainly used software powered by MySQL. WordPress, YouTube, early Facebook, and countless web applications have used it to store their data.

It didn't start as a big corporate project. Back in 1995, two Swedish developers built it because they needed a simple, fast database for small projects. Over three decades, three different corporate owners, and a major split in the open-source community, MySQL is still around and getting updated.

Here is a look at how MySQL went from version 1.0 to where it is today.

1995–2005: The Early Years
Michael "Monty" Widenius and David Axmark released MySQL 1.0 in 1995. Their goal wasn't to build something to replace complex commercial databases like Oracle or DB2. They just wanted something fast, simple, and free. That made it a popular choice for early websites that needed a basic database without a high price tag.

MySQL 3.23 (2001)
Version 3.23 was the first release that felt fully ready for serious use. It came with two different storage engines: MyISAM for quick reads and InnoDB for handling transactions securely. It also brought replication, which let developers copy data across multiple servers so websites could handle more traffic.
MySQL 4.0 and 4.1 (2003–2004)
    4.0 (2003): Added query caching and UNION statements to improve speed and SQL support.
    4.1 (2004): Added subqueries, prepared statements, and better character sets, making it much easier for developers to build real applications without using messy workarounds.

MySQL 5.0 (2005)
This release added features that traditional database administrators expected, such as stored procedures, triggers, views, and cursors. This allowed teams to run logic directly inside the database itself.

2008–2009: Sun Microsystems
By 2008, MySQL had grown so large that Sun Microsystems bought the company behind it for about $1 billion. This gave MySQL corporate backing and brought it into larger company environments.

MySQL 5.1 (2008):
This version brought table partitioning, an event scheduler, and a plugin API. Table partitioning was especially helpful because it allowed people to break up huge tables into manageable pieces without breaking their applications.

2010–2015: Oracle Takes Over
Sun didn't own MySQL for long. In 2010, Oracle acquired Sun.
Many people in the open-source community were worried that Oracle would slow down development on MySQL to protect its paid database products. In fact, Monty Widenius started a separate database called MariaDB around this time just in case. But Oracle ended up continuing to develop and fund MySQL.

MySQL 5.5 (2010)
Oracle made InnoDB the default storage engine, replacing MyISAM. This made sense because most production systems were already using InnoDB for its reliability and safety during system crashes.

MySQL 5.6 (2013)
This release focused on performance. It included a better query optimizer, full-text search for InnoDB, and a Memcached API so developers could do quick key-value lookups without extra software.

MySQL 5.7 (2015)
The biggest feature in 5.7 was support for native JSON data. This meant developers could store unstructured JSON documents right alongside standard tables, reducing the need to run a separate NoSQL database like MongoDB.

2018: MySQL 8.0
Instead of releasing a version 6 or 7, Oracle jumped straight to MySQL 8.0 in 2018. It was a large update that included:
    Common Table Expressions (CTEs) and Window Functions to make complex reporting queries easier to write.
    Atomic DDL, which meant database structural changes either completed entirely or rolled back cleanly if something broke.
    Better security roles and an improved transactional data dictionary.

2024–Present: The New Release Model and AI Features
In 2024, Oracle changed how they release MySQL. They split updates into two types:
    Long-Term Support (LTS): Stable versions meant for production systems where you don't want unexpected changes.
    Innovation Releases: Quarterly releases that bring new features more quickly.

MySQL 8.4 LTS (2024)
This was the first official Long-Term Support release under the new model, giving companies a stable version they can run for years without major changes.

MySQL 9.x Innovation & MySQL 9.7 LTS (2024–2026)

Throughout 2024 and 2025, the 9.x Innovation releases introduced modern capabilities, including a native VECTOR data type for AI embeddings and similarity search.

In April 2026, Oracle released MySQL 9.7 LTS, marking the next long-term support milestone after 8.4. Rather than just being a maintenance bump, 9.7 brought several features down into the free Community Edition that used to be paid Enterprise exclusives:

• Hypergraph Optimizer: A rewritten query optimizer that handles complex joins and query execution plans much better.

• JSON Duality Views: Allows developers to insert, update, or read data as JSON documents while storing it as relational tables.

• OpenTelemetry Support: Built-in observability metrics and tracing so operations teams can monitor database performance using standard tools.

• Replication Improvements: Added detailed statistics on replication lag and automatic cluster eviction for unhealthy nodes to keep high-availability setups reliable.

MySQL Major & Minor Release History

Major Version	Series / Track / Model Type	General Availability (GA) Date	Latest Minor Version	Latest Release Date	End of Support (EOL)
MySQL 3.19	Early	Late 1996	3.19.5	1997	Legacy
MySQL 3.20	Early	January 1997	3.20.32a	1997	Legacy
MySQL 3.21	Early	1998	3.21.33	1998	Legacy
MySQL 3.22	Early	1998	3.22.32	1999	Legacy
MySQL 3.23	Early	January 22, 2001	3.23.58	December 2003	Legacy
MySQL 4.0	Major	March 2003	4.0.30	March 2007	December 2008
MySQL 4.1	Major	October 2004	4.1.25	November 2007	December 2009
MySQL 5.0	Major	October 2005	5.0.96	March 2012	December 2011
MySQL 5.1	Major / Retrospective LTS	November 14, 2008	5.1.73	December 3, 2013	December 2013
MySQL 5.5	Major / Retrospective LTS	December 3, 2010	5.5.62	October 22, 2018	December 2018
MySQL 5.6	Major / Retrospective LTS	February 5, 2013	5.6.51	January 20, 2021	February 2021
MySQL 5.7	Major / Retrospective LTS	October 21, 2015	5.7.44	October 25, 2023	October 2023
MySQL 8.0	Major (Pre-LTS Model)	April 19, 2018	8.0.46	April 21, 2026	April 2026
MySQL 8.1	Innovation	July 18, 2023	8.1.0	July 18, 2023	October 2023
MySQL 8.2	Innovation	October 25, 2023	8.2.0	October 25, 2023	January 2024
MySQL 8.3	Innovation	January 16, 2024	8.3.0	January 16, 2024	April 2024
MySQL 8.4	Long-Term Support (LTS)	April 30, 2024	8.4.11	July 28, 2026	April 2032
MySQL 9.0	Innovation	July 1, 2024	9.0.1	July 23, 2024	October 2024
MySQL 9.1	Innovation	October 15, 2024	9.1.0	October 15, 2024	January 2025
MySQL 9.2	Innovation	January 21, 2025	9.2.0	January 21, 2025	April 2025
MySQL 9.3	Innovation	April 15, 2025	9.3.0	April 15, 2025	July 2025
MySQL 9.4	Innovation	July 22, 2025	9.4.0	July 22, 2025	October 2025
MySQL 9.5	Innovation	October 21, 2025	9.5.0	October 21, 2025	January 2026
MySQL 9.6	Innovation	January 20, 2026	9.6.0	January 20, 2026	April 2026
MySQL 9.7	Long-Term Support (LTS)	April 21, 2026	9.7.2	July 28, 2026	April 2034

 

Massive Kubernetes: Comparing EKS, OKE, GKE, and AKS on Scale, Costs, and Reality

Kubernetes was never really built with a hard cap on cluster size, but every major cloud provider puts one on it anyway. Why? Because the underlying engine (etcd, the API server, and the scheduler) can only track and process so much data before things start falling apart.

Over the last couple of years, the big four managed services—AWS (EKS), Oracle (OKE), Google (GKE), and Microsoft (AKS)—have been pushing those caps higher and higher. But they aren't doing it for the same reasons, nor are they building it the same way.

Here is where the max worker nodes per cluster stand right now:

Cloud Provider	Max Nodes / Cluster	Previous Limit	Jump
AWS EKS	100,000	5,000	20x
OCI OKE	20,000	5,000	4x
Google GKE	15,000	5,000	3x
Azure AKS	5,000	~1,000–5,000	Current ceiling

 

What’s driving these massive numbers?
AWS went all-in on AI. AWS raised the EKS ceiling to a massive 100,000 nodes. But this isn't for standard microservices—it's built specifically for giant AI and machine learning workloads. When you're training a massive model across tens of thousands of GPUs, splitting that job across multiple separate clusters is a nightmare. AWS built this so everything can live in one single place.

Oracle is chasing the same crowd. Oracle pushed OKE up to 20,000 nodes. Similar to AWS, they are targeting heavy compute and AI jobs. However, Oracle doesn't just hand you this limit out of the box—you have to meet specific setup requirements to unlock it.

Google takes an engineering approach. GKE supports 15,000 nodes. Google builds its control plane on top of Spanner (their massive distributed database), so they treat this limit less like a marketing stunt and more like an engineering rule based on what their backend can comfortably hold.

Azure is sitting comfortable at 5,000. AKS tops out at 5,000 nodes, which used to be the industry standard limit across the board. Microsoft hasn't rushed to join the mega-cluster war yet, focusing instead on feature stability and node pool limits (where individual pools cap at 1,000 nodes). 

What "Extreme Scale" Actually Takes
Those big headlines hide a lot of fine print. Before you go building a 20,000-node cluster, keep these realities in mind:
1. Oracle hides scale behind an upgrade tier
To cross that 5,000-node mark in OKE, you can’t use the standard free "Basic" tier. You have to move to "OKE Enhanced," run a recent version of Kubernetes, and turn on specific encryption tools. Enhanced clusters give you a proper money-backed uptime guarantee (SLA) along with extra enterprise features, but it means reaching extreme scale requires paying for a higher management tier.

2. AWS built a tool for a specific job
Just because EKS can run 100,000 nodes doesn't mean you should move your company's web apps into one giant cluster. AWS explicitly framed this upgrade around AI training. If you aren't running massive distributed jobs that require raw GPU-to-GPU coordination, a massive cluster just adds risk.

3. Google cares about workload density, not just node count
Google's guidelines are refreshingly honest: node count isn't the only thing that breaks a cluster. If you run thousands of tiny pods that create, crash, and restart constantly, you will overwhelm the API server long before you hit 15,000 physical machines.

4. Azure’s limits depend on how you set it up
With AKS, hitting 5,000 nodes requires using standard load balancers and Virtual Machine Scale Sets. If you fall back to basic networking setups, your limit plummets to 100 nodes. Furthermore, while Azure offers a completely free control plane tier, Microsoft warns against running more than 10 nodes on it for real production workloads.

What Does it Cost?
When it comes to base control plane pricing, all four providers have basically settled on the same price:

• The baseline cost across the board is $0.10 per cluster, per hour.
• That comes out to roughly $74 a month just to keep the cluster's control plane alive.

However, the real differences come out in the extra options:
AWS EKS: Offers high-performance control planes for extra-heavy API loads (costing anywhere from $1.65 to over $13 an hour), plus an extended support fee if you refuse to upgrade older Kubernetes versions.

Google GKE: Gives you a ~$74 monthly credit that basically makes your first basic cluster's control plane free. They also offer Autopilot, which changes the game entirely: instead of paying for the servers in your cluster, you only pay for the exact CPU, RAM, and storage your individual pods use.

Azure AKS & Oracle OKE: Both offer totally free control planes on their basic tiers (you only pay for the underlying VMs). But if you want financial uptime guarantees or massive scale, you have to jump to their $0.10/hour paid tiers.

Takeaway on cost: For 99% of teams, the control plane fee is just noise. The real money goes to the compute instances (the actual servers) running your workloads.

Operational Reality: What Actually Breaks First?
If you talk to the engineers who maintain these platforms, they’ll all tell you the same thing: The node cap isn't usually what breaks your cluster.

When clusters fall over at scale, it’s usually because of:
Network exhaustion: Running out of IP addresses in your subnet for pods and services.
Container registry bottlenecks: Trying to pull a 10GB Docker image to 5,000 machines at the exact same second.
API server overload: Thousands of pods constantly talking to the cluster control plane at once.

In fact, the official documentation for almost all of these providers quietly says the same thing: Don't build one giant cluster if you don't have to.
For almost every company, running four or five medium-sized clusters is much safer than running one mega-cluster. It isolates failures, makes updates less terrifying, and lets different teams move at their own pace.

Unless you're training a massive AI model, don't worry too much about who has the biggest number. Focus on SLA tiers, how easy it is to manage multiple small clusters, and how compute costs fit your budget.

Oracle Critical Patch Updates and Critical Security Patch Updates: What You Need to Know Before July 21, 2026

Oracle's security patching calendar just got a lot busier — and a lot more important to track. With a new Critical Patch Update landing this week and Critical Security Patch Updates now filling the gaps between quarterly releases, DBAs and security teams have more patch windows to plan around than ever before. Here's a rundown of what these programs are, what's changed recently, and what you should be doing right now.

What is a Critical Patch Update (CPU)?

Critical Patch Updates provide security patches for supported Oracle on-premises products. A CPU is a collection of patches addressing multiple security vulnerabilities — both in Oracle's own code and in third-party components bundled into Oracle products. These patches are usually cumulative, meaning a current CPU typically rolls up fixes from prior releases, and they're available to customers with valid support contracts.

CPUs are released on a predictable quarterly cadence: the third Tuesday of January, April, July, and October. The upcoming schedule is:

• 21 July 2026
• 20 October 2026
• 19 January 2027
• 20 April 2027

What is a Critical Security Patch Update (CSPU)?

Newer to Oracle's lineup, Critical Security Patch Updates provide targeted, high-priority security fixes in a smaller, more focused format — designed to be easier to apply with minimal disruption than a full quarterly CPU. Rather than replacing the CPU program, CSPUs complement it, giving customers more frequent opportunities to close out high-priority vulnerabilities between the big quarterly releases. Like CPUs, they require a valid support contract.

Oracle released the first Critical Security Patch Update on May 28, 2026, and has continued the cadence with a June 2026 release. Going forward, CSPUs land on the third Tuesday of February, March, May, June, August, September, November, and December — effectively filling every month that doesn't already have a CPU. The upcoming CSPU dates are:

• 18 August 2026
• 15 September 2026
• 17 November 2026
• 15 December 2026

Put together, CPUs and CSPUs mean Oracle now ships a security update essentially every month of the year.

Where things stand as of July 2026

Checking Oracle's Critical Patch Updates, Critical Security Patch Updates, Security Alerts and Bulletins page, the most recently completed quarterly release is the April 2026 CPU (Revision 2, published April 24, 2026). Since then, Oracle has issued two Critical Security Patch Updates — May 2026 (Rev 1, May 28) and June 2026 (Rev 1, June 16) — along with standalone security alerts for individual high-impact CVEs, including CVE-2026-35273 (Rev 1, June 10, 2026).

That brings us to the next big date on the calendar: July 21, 2026, when the next quarterly Critical Patch Update is due.

Why the July 2026 CPU deserves extra attention

Early advisory details point to this being a heavier-than-usual release. Reports on the pre-release notification indicate the July 2026 CPU addresses roughly 5 critical-severity vulnerabilities (CVSS 9.0+) and 12 or more high-severity flaws, spread across widely deployed products including Oracle WebLogic Server, PeopleSoft, Oracle Identity Manager, Oracle WebCenter, WebCenter Capture, and Oracle VirtualBox.

The most serious issue flagged so far is a pre-authentication remote code execution vulnerability in PeopleSoft (CVSS 9.8), which is reportedly already being actively exploited in the wild in combination with CVE-2026-35273 by a known threat actor group. Other near-maximum-severity issues include unauthenticated RCE vulnerabilities in WebLogic Server (CVSS 9.9) and Identity Manager (CVSS 9.9), plus two HTTP-exploitable RCE flaws in WebCenter Capture (CVSS 9.9 each).

If you run PeopleSoft, WebLogic, Identity Manager, or WebCenter in production, this isn't a "patch it next month" release — it's a "get it on the calendar for this week" release, especially given the active exploitation reports.

Why Oracle is pushing faster patching, not just more patches

A recent Oracle Database blog post, Prepare Now: Apply the Upcoming Oracle Database Release Update Immediately Upon Availability, makes the case for why this matters beyond any single CVE. The post urges customers to prepare now for the upcoming Database Release Update — including Oracle Database 19c Release Update 19.32 and Oracle AI Database 26ai Release Update 23.26.3 — and to apply it promptly across all systems once it's available.

AI models are accelerating both vulnerability discovery and exploitation, and are increasingly capable of chaining multiple weaknesses across the application and data stack into complex, multi-step attacks. In other words, the gap between a vulnerability becoming public and it being weaponized is shrinking, which shrinks the safe window for "we'll get to it next sprint" patching.

Oracle's specific pre-release recommendations include:

• Inventorying all database infrastructure components so nothing gets missed
• Confirming systems are running supported Long-Term Support releases
• Taking advantage of Oracle's complimentary patching and security tooling
• Building out accelerated testing procedures so patches don't stall in QA
• Reviewing high-availability technologies to enable minimal-downtime deployment
• Validating backup and recovery processes before, not after, you need them

What this means for your patch calendar

With CPUs and CSPUs now running nearly every month, ad hoc patching is no longer a workable strategy. A few practical takeaways:

1. Build the recurring cadence into your change management process now. Third-Tuesday releases are predictable — there's no reason to be caught off guard by them.
2. Treat CSPUs as real work, not optional extras. They're smaller by design, but they exist specifically to close high-priority gaps between quarterly CPUs.
3. Prioritize by exploitability, not just CVSS score. The July 2026 CPU is a good example — actively exploited flaws (like the PeopleSoft RCE) should jump the queue regardless of what else is in the release.
4. Pre-stage your testing and HA/downtime plans before the release drops, following Oracle's own guidance, so the time between "patch available" and "patch applied in production" is measured in days, not weeks.

Sources:

• Oracle Critical Patch Updates, Critical Security Patch Updates, Security Alerts and Bulletins
• Prepare Now: Apply the Upcoming Oracle Database Release Update Immediately Upon Availability – Oracle Database Blog

 

Oracle Database 19.31 Patch Hold: What DBAs on Exadata 25.2 Need to Know

If you’ve been trying to download the latest Oracle Database 19.31 Release Update (RU) lately and found the download pages curiously empty, you aren't alone. Oracle has officially placed a temporary hold on this specific RU for Exadata environments.

The move comes after several customers reported intermittent internal errors specifically when running 19.31 on Exadata System Software 25.2. Here is a breakdown of what happened, why it matters, and how to keep your systems stable.

What’s the Problem?
Oracle recently published a My Oracle Support (MOS) advisory regarding a conflict between the 19.31 DBRU and the newer Exadata 25.2 software stack. It appears that a specific optimization path related to temporary tablespace processing is triggering internal failures during SQL execution.

Because the issue is severe enough to cause application instability, Oracle took the proactive step of removing the 19.31 patch binaries while they work on a corrected revision.
Key Symptoms to Watch For:
If you are already on this combination, you might see a spike in:

• ORA-00600 internal errors (specifically signatures like QERHNITERATEOVERBUFFERS.1 or kcblsltio_1)
• Unexpected SQL statement failures and session terminations
• Background process crashes that disrupt application uptime

Issues specifically during heavy ETL, analytics, or workloads that lean hard on temporary segments.

Workaround: Disabling the Optimization
If you have already deployed 19.31 to your Exadata 25.2 environment, you don't necessarily need to roll back immediately. Oracle has provided a "hidden parameter" workaround that disables the problematic optimization path.

To mitigate the risk immediately, run the following:
-- For the current instance
alter system set "_kcfis_fctempopt_mode" = 0;

-- For RAC environments (persistent across nodes)
alter system set "_kcfis_fctempopt_mode" = 0 scope=both sid='*';

Note: As with any hidden parameter, make sure to document this in your operational runbook and monitor performance. Once Oracle releases the corrected RU, you will likely need to unset this parameter.

Who is Affected?
The good news is that this is a relatively narrow issue. It currently only impacts:
Database Version: 19.31
Infrastructure: Exadata System Software 25.2.*
If you are running 19.31 on standard Linux/Unix servers, or if your Exadata units are on older software versions, you are likely in the clear.

reference: We released a MOS Note with detailed information: (KB888427) Oracle Database 19.31 Patch Hold Due to ORA-00600 Errors on Exadata 25.2: 

Copy Fail: The New "Dirty Pipe" Haunting the Linux Kernel (CVE-2026-31431)

1. What is Copy Fail (CVE-2026-31431)?
Copy Fail is a logic flaw in the Linux kernel's crypto-subsystem (specifically the algif_aead module). It allows an unprivileged user to gain full root access in seconds.  

Root Cause: A performance optimization introduced in 2017 allowed the kernel to perform in-place cryptographic operations (reusing the same memory for input and output).  

Flaw: By using the splice() system call, an attacker can trick the kernel into using the Page Cache (the kernel’s in-memory copy of files) as a writable buffer.

Result: An attacker can perform a controlled 4-byte write into any readable file in memory. They typically target a binary like /usr/bin/su to change its logic on the fly and grant themselves root privileges without ever touching the actual file on the disk.
 
2. Why it’s Critical for Cloud & Kubernetes
This is particularly dangerous for multi-tenant environments:
Container Breakout: Because the Page Cache is shared across the entire host kernel, a user in one container can corrupt a file that affects the host and all other containers on that node.  

Reliability: Unlike many exploits that rely on race conditions (timing luck), Copy Fail is deterministic. It works every time, regardless of system speed or load.  

Small Footprint: The exploit can be triggered by a script as small as 732 bytes.
        
3.High-Level Comparison: 
Copy Fail vs. Dirty Pipe If your stakeholders remember Dirty Pipe (2022), this is its modern sibling.  
Feature                   Dirty Pipe (CVE-2022-0847)      Copy Fail (CVE-2026-31431)
SubsystemPipe      Buffer / Splice                                Crypto API / Splice
Trigger                    Uninitialized pipe flags                AEAD in-place logic flaw
Scope                       Linux Kernels 5.8+                       Every major distro since 2017
Detection               Moderate (File modifications)    Difficult (Direct Memory corruption)


    

Oracle 26 AI New DB Parameter CALENDAR_FISCAL_YEAR_START

Business doesn’t follow the January to December calendar, but the database does. Every time you build a report, a dashboard, or even a simple query, you end up rewriting the same fiscal logic again and again.
Some teams maintain calendar tables. Others push the logic into BI tools. In many cases, it ends up duplicated across ETL pipelines, reports, and applications. And sooner or later, something goes out of sync.

Oracle 26ai introduces a small but very practical fix for this: CALENDAR_FISCAL_YEAR_START.
Checking the Parameter
show parameter CALENDAR_FISCAL_YEAR_START
NAME                       TYPE   VALUE 
-------------------------- ------ ----- 
calendar_fiscal_year_start string       

At this point it’s unset, which means Oracle is still operating on the standard calendar year.

Set the start of the fiscal year to June 1:
ALTER SESSION SET CALENDAR_FISCAL_YEAR_START = '01-JUN-2026', 'DD-MON-YYYY';

Only the month and day really matter, so this works as well:
ALTER SESSION SET CALENDAR_FISCAL_YEAR_START = '01-JUN', 'DD-MON';

Now let’s see how Oracle interprets dates once this is set.
Check June 15, 2026:
SELECT FISCAL_QUARTER('15-JUN-2026');
FISCAL_QUARTER
-------------
Q1-FY2027

And May 15, 2026:
SELECT FISCAL_QUARTER('15-MAY-2026');
FISCAL_QUARTER
-------------
Q4-FY2026

This is exactly how most organizations expect fiscal periods to behave when the year starts in June.

Why This Actually Matters:
This parameter removes a lot of quiet complexity that has been sitting in systems for years.
First, it cleans up SQL. You don’t need CASE statements or custom logic just to determine fiscal quarters. The database understands it natively.
Second, it brings consistency. Instead of every layer calculating fiscal periods differently, the logic lives in one place. That alone eliminates a lot of subtle reporting issues.
Third, it simplifies data pipelines. There’s no need to maintain fiscal calendar tables or transformation logic in ETL jobs. Less code, fewer moving parts, fewer things to break.

What is Ollama Serve (REST API)

Running LLMs locally is becoming very common, and tools like Ollama make it extremely simple.
But one feature that really unlocks its power is ollama serve
This turns your local machine into a REST API server for AI models.

When we run:
ollama serve

It starts a local web server. This server allows other applications to talk to your AI models using HTTP requests.

Without serve → You manually run prompts in terminal
With serve → Your apps can call the model like an API

Default API Endpoint: Once the server starts
http://localhost:11434  becomes base URL.

Example API Call
Here’s a  request:
curl http://localhost:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "Explain cloud computing"
}'

Sample API Output (With Metrics):
{
  "model": "llama3",
  "created_at": "2026-04-18T12:10:00Z",
  "response": "Cloud computing is the delivery of computing services over the internet...",
  "done": true,

  "total_duration": 2450000000,
  "load_duration": 800000000,
  "prompt_eval_count": 12,
  "prompt_eval_duration": 200000000,
  "eval_count": 65,
  "eval_duration": 1450000000
}

Now let’s understand this response
Basic Response Fields
model  ===> llama3
created_at  ===>  2026-04-18T12:10:00Z
response    ===>  "Cloud computing is the delivery of computing services over the internet..."
done    ===>  true , Means response is complete, No more data coming

Performance Metrics:
1. total_duration ===>   2450000000 ns → ~2.45 seconds
This is the total time taken ==> From Request received To Final response sent

2. load_duration  ===> 800000000 ns → ~0.8 seconds
Time taken to load the model into memory 
This usually happens On first request ,When model is not already loaded

3. prompt_eval_count  ===>  12 tokens
Number of tokens in your input  

4. prompt_eval_duration   ===>  200000000 ns → ~0.2 seconds
Time model spent reading your question

5. eval_count    ===>  65 tokens
Number of tokens generated in response , This directly affects response size,Cost (in cloud scenarios) and Latency

6. eval_duration    ===>  1450000000 ns → ~1.45 seconds
Time spent generating the response , This is Actual thinking + answering time

Understanding LLM Models: Basics That Help You Choose the Right One

LLMs are everywhere now. Every tool, every platform, every new feature seems to be powered by them.

But when it comes to actually choosing a model, things quickly get confusing.
You start seeing terms like parameters, quantization, context length… and it all feels a bit heavy

This blog will help you understand the key basics in a simple way.

Model Architecture – How the Model Thinks
At a high level, architecture is just how the model is designed to process information.  
Most modern LLMs use something called a Transformer. You don’t need to go deep into it — just know this:
It helps the model understand relationships between words.
Instead of reading text word-by-word like old systems, it looks at the whole sentence and figures out what matters more.
That’s how it understands meaning, tone, and context.

Why should you care?
Because better architecture usually means:
More accurate responses
Better understanding of complex inputs
Smarter outputs overall

Parameters – How Big the Model Is
This is the one you’ll hear the most.

Parameters are basically the size of the model.
More parameters = more “learned knowledge”.

Think of it like this:
Small models are quick and efficient
Large models are more knowledgeable but heavier

But bigger isn’t always better.

Yes, large models can reason better and handle complex tasks.
But they also:
Cost more
Need more compute
Can be slower

So the real question is not “What’s the biggest model?”
It’s “What’s enough for my use case?”

Quantization – Making Models Practical
Quantization is simply a way to make models smaller and faster. Without it, most large language models would be too heavy to run outside of high-end infrastructure.

What “Quantization” Really Means
LLMs normally store weights in high precision like:
FP32 (32-bit float)
FP16 (16-bit float)

Quantization reduces that to:
8-bit (Q8)
6-bit (Q6)
5-bit (Q5)
4-bit (Q4)

So instead of each weight taking 16–32 bits, it might take just 4 bits.
Result:
Much smaller model size
Faster inference
Can run on CPU or smaller GPUs

But:
Slight loss in quality (depends on method)

And honestly, in many real-world cases, that quality drop is barely noticeable. Especially for things like chat, summaries, or general-purpose usage.

You’re basically making a smart trade:
a tiny bit of precision for a huge gain in usability

Where It Gets Slightly Confusing (But Important)
Once you start using quantized models, you’ll see names like:
Q4_0
Q4_1
Q4_K_M
Q4_K_S

At first, it looks like random naming. But there’s actually a simple idea behind it.
Q4 → means 4-bit quantization
The part after _ → tells you how the compression is done
Not All Q4 Are Equal

Older versions like:
Q4_0 → more aggressive, lower quality
Q4_1 → slightly better

Smarter Quantization (The K Family)
Q4_K_M
Q4_K_S

use better techniques (you’ll often see them in tools like llama.cpp).

Instead of compressing everything the same way, they:
Work in small blocks
Apply smarter scaling
Keep important information more intact

Same 4-bit size, but noticeably better quality.
Picking the Right One (Simple Rule)
Q4_K_M → best balance (default choice)
Q4_K_S → slightly faster, slightly less accurate

If you don’t want to overthink it, just go with Q4_K_M.

 
Context Length – How Much It Can Keep in Mind
Context length is like the model’s short-term memory.

It decides how much text the model can look at in one go.
Short context:
Faster
Cheaper
But forgets earlier parts quickly

Long context:
Can handle long documents
Better for conversations and analysis
Slightly more expensive

If your work involves long PDFs, logs, or conversations — this matters a lot.

Embedding Length – How Well It Understands Meaning
This one is less talked about, but very important.

Before a model understands text, it converts words into numbers. These are called embeddings.

Embedding length is just how detailed that representation is.
Higher dimension → richer understanding of meaning

This becomes critical when you're building things like:
Search systems
Recommendations
RAG (retrieval-based AI apps)

If your use case involves “finding similar things” — embeddings matter more than you think.

So, How Do You Choose?
Instead of chasing the biggest or newest model, think in terms of your actual need.

If you need deep reasoning → go for larger models
If you need speed and cost efficiency → smaller + quantized models
If you deal with long inputs → prioritize context length
If you're building search or RAG → focus on embedding quality

It’s always a trade-off. There’s no perfect model.